A quick perusal of the
IO::Socket::SSL POD reveals that
- new_from_fd explicitly ignores its mode argument so you may as well leave it off
- You can use IO::Socket::SSL::errstr() immediately after the new_from_fd to see what went wrong (or at least, given that you're getting undef back from IO::Socket::SSL->new_from_fd, you should get the text of some error message, whether this has direct bearing on the problem or not...)
- This module is not thread-safe, so basically all bets are off. While it admits some possibility of working if you're not using SSL_verify_callback or SSL_password_cb, I'd say the bottom line here is that since the module author has evidently not done the work to make sure IO::Socket::SSL can be used across threads, there's probably a reason, i.e., something that was too difficult to deal with in C code, that you're clearly not going to be able to address from pure Perl, and unless the previous two points turn up something obvious that you can fix and that happens to work (that you may still not want to trust), you'll probably want to try some completely different approach
update:
I'm also skeptical that
new_from_fd could ever actually do what you want, since an SSL connection has a huge pile of state associated with it, e.g., the choice of cipher, the actual keys in use, etc... information that simply cannot be derived from the underlying file descriptor; you
have to copy it in from the handle object in the other thread somehow. As far as I can tell, a
new_from_fd call from another thread on an already-open socket would have to renegotiate a new SSL session from scratch.
Oddly enough, copying of a structure like IO::Handle/Socket happens automatically when you create a new thread. And this tends to work fine in the case of a pure perl structure, in which case referring to the same variable in a different thread will refer to the clone and you're done.
But when you have an object created directly by C code, then you'll have an underlying C structure, and unless the module author explicitly did something about this — what it means to make the module thread-safe — the C structure will be shared by the various perl clones, which are all assuming they each have the C structure all to themselves, at which point things will go to hell the first time you use the object from a different thread (i.e., because it's a different clone with the wrong perl state).
The only way this has any chance of working is if you exclusively use the handle object in the parent thread prior to the child thread being created, never use it in the parent thread thereafter (not even to close it), always use it from that child thread from then on, closing it from that child thread once you're done with it.
And if this usage pattern doesn't fit the design of your code, you're going to lose...)
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.