in reply to Re: SSL-socket on Windows
in thread SSL-socket on Windows

the start of a "merry trip through hell".
Thanks for the encouragement :-)

I did some more testing and found that the start_SSL actually does seem to return eventually, even though it can take half an hour...

The problem I face at the moment is the following:

One thread connects the socket (non-SSL), then the socket gets passed to a "main" thread that tries to upgrade the socket to SSL and also handles several other sockets with a select-loop but because the start_SLL takes so long yet another "monitor"-thread decides that the main thread is dead and restarts the whole thing after which the cycle repeats.

I have no idea why it was implemented like that (one thread making the TCP-connection and another upgrading it to SSL), but I hope I can make the thread that connects also do the SSL-upgrade and then pass the SSL-socket to the main-thread to avoid blocking it for so long.

I hope (and pray) that as at any given time there is only one thread using the SSL-socket that the thread-unsafeness of IO::Socket::SSL will not be an issue for me - or would you say that you cannot pass a SSL-socket from one thread to another and my plan is doomed?

Replies are listed 'Best First'.
Re^3: SSL-socket on Windows
by bulk88 (Priest) on Mar 18, 2012 at 04:40 UTC
    Get a copy of Visual Studio. Download the symbols.zip package ActiveState offers. Attach the debugger to the perl process, and see what the C level callstack looks like. Non-blocking socket, not file/disk/serial, I/O works on windows. select() does work, again only on sockets. Ithreads is a *****. You might be "cloning" the socket or getting a NULL/undef socket when you pass it between ithreads. Just a random guess.
[reply]
Re^3: SSL-socket on Windows
by Marshall (Canon) on Mar 18, 2012 at 13:27 UTC
    Since I haven't actually done this myself, I can't say for sure that this is going to work, but you can pass a normal socket, so I would suppose that is ok for an SSL socket. This is indeed a strange design. But you plan sounds like its worth a shot.
[reply]
      Unfortunately I've hit a wall now.

      I cannot directly share the IO::Socket::SSL - I get an error if I try.

      So I guess the only way forward now is not to share the SSL-object but the unterlying filehandle and try to reconstruct the SSL-object in the other tread using that.

      Does anyone have an idea if this is feasible or are there any other approaches to sharing IO::Socket::SSL instances among threads?

      As I said there will only be one thread using this instance at any given time, so thread-safeness (or the lack of it) should not affect me.

[reply]
        I have no idea why it was implemented like that (one thread making the TCP-connection and another upgrading it to SSL),

        This just sounds very bizarre to me! You may have to fix this which sounds like an fundamental problem? I've never had to "upgrade" a connection to SSL after successful connection to a particular IP/port combination - in my experience, I have to start that way or the server won't talk to me at all!

        Is there a way to "dumb the code" down so that the other Monks can work on it?

        The SSL connection should happen fast (like 1+ second, not 30 minutes). Your credentials work or they don't work. I guess this also has to do whatever you are connecting to!

[reply]

In Section Seekers of Perl Wisdom