in reply to Re: Multiplexing HTTPS server, peer cert authentication problem. in thread Multiplexing HTTPS server, peer cert authentication problem.
Ah, so you're talking about multiple listeners for the same socket - "bound" before the inital fork(), where only one process actually succeeds to accept() for a given incoming request ?
Does that work with threads ? :)
I only ask because I've looked into the magic that Threads.pm does to clone (copy) non-shared variables into new threads... specifically, that does bad things to the self-glob-ref thing that IO::Socket::SSL does internally.
-David.
Re^3: Multiplexing HTTPS server, peer cert authentication problem.
by Moron (Curate) on Mar 06, 2007 at 10:40 UTC
|
If you are sticking with threads, you can pass objects to threads using the Thread::Queue module. In fact that is also the recommended (big Camel book) way to synchronise the handling of asynchronous requests under those circumstances, although if you use it to meet both requirements you'd need N+1 queues where N is the number of startup threads - one to synchronise requests to the request-handling synchronous daemon and one for each startup daemonet to receive object data from the initialising parent.
And if the threads approach remains too troublesome, you could always spawn the daemonets with something like for (1..$nrDmnts) { my $pid = open my $ph, "|-" ... } instead and send them non-shared data across the pipe.
| [reply] |
|
In my real server, I *am* actually using Thread::Queue::Any to farm out work to my worker threads from my multiplexing server.
The code I posted is my (boilded down for SoPW) attempt at making my *mostly* non-blocking server *fully* non-blocking. (I see from Thelonius's suggestion that I may not have finished the job). The real server replaces the "file" code from the OP with a mechanism to send work to a Dispatcher thread which classifies the request, finds an appropriate handler class then farms the "work" out to a pool of worker threads.
I can't actually import Threads.pm into the multiplexing server's package as some "magic" internal to Threads.pm causes crashes in IO::Socket::SSL (actually XS from Net::SSLeay).
As for the excellently old-skool open "|blah" method of IPC, i would use it in a second (over say Thread::Queue::Any) if there was currently any problem with the IPC -- I do not believe this to be the case.
-David.
| [reply] |
|
I am suggesting repairing the SSL data by sending it across from a parent process. The open "|blah" suggestion is a last resort option to prevent the need for Threads, not because there are any problems with IPC.
| [reply] |
|
|
|
|