Just to clarify—you are saying that the concerns in IO::Socket::SSL + fork problem do not apply in this case?
How do you envision such socket being managed? Perusing threads::shared and my $sock :shared; will ensure coherent state? The Net::SSLeay itself is thread-safe, but does it support shared sockets? Any special concerns, such as nonblocking mode or cross-thread callbacks?
| [reply]
[d/l] |
Once the SSL socket is established all the necessary state for reading and writing is fully managed by the OpenSSL library. That is the Perl socket can be used between multiple threads, but only one thread should use the socket at one time (i.e. needs locking). Forking is different because in this case the SSL state gets duplicated and client and server try to manage their own state independently which will not work because then none of these will reflect the real state of the SSL connection.
Of course all this means that the Socket must be created before the threads are created. Creating a socket in one thread and then using it in another will not work since the Perl handle can not be shared.
| [reply] |
And yet, one thought that keeps banging against my head is this: “even if we can ‘make it to work,” does it ‘make sense?’” That, to me, is actually a key question here: “does it actually ‘make sense’ that one thread should ‘only read,’ and that another thread, ‘only write?’” I don’t think so. Why? Because somebody needs to be aware of: “the present-state of the remote client.” And, furthermore, this “present-state” can only be ascertained, subject to an unforeseen (and, unforeseeable ...) lag.
Therefore, I suggest that the only truly-practicable design must be this: “put your letter in the box, raise the flag, and then wait for the postman.” “The Postman” has no race-conditions within himself. Therefore, he is able to efficiently serve the needs of any number of clients without conflict.
To my way of thinking, both of the client-processes in question should be reading/writing from queues that are served by the Postman. They should not be attempting to read/write from the socket directly.
| |