Err, no :) It's a bit more complicated (for good reason).

Indeed the HTTPS (original, unposted) server is single-threaded and embarassingly multiplexed (accept only). It has a reference to a "Dispatcher" object - also in the same thread.

The Dispatcher object when instantiated creates two Thread::Queue::Any objects. It does (obviously) import Threads, but is passed to the HTTPS server's package in such a way as that package does *not* import Threads.

After creating the queue objects, Dispatcher's constructor creates a new thread, passing it the two queue objects, wherein the new thread enters a loop dequeuing requests from one queue, and enqueuing responses to the other queue.

The HTTPS daemon accesses the Dispatcher through its methods: dispatchRequest, pendingReponses, retrieveResponse. Those methods interact *only* with the two queue objects (always in the main thread in which the HTTPS daemon resides).

Why?

IO::Socket::SSL objects break badly when Threads is imported in the same scope (and "no threads" doesn't help ;)

That whole mess was devised so that the work implied by HTTPS requests could be farmed out to a number of "worker" threads from the Dispatcher, without ever letting the HTTPS server's package be exposed to the Threads module.

All of that was quite successful. Thelonius and yourself are quite right to suggest that the SSL handshakes were being missed while previous (blocking) requests were being serviced. The code in the OP was almost there, however the state-machine was wrong because it did not fully emulate the work done by IO::Socket::SSL's accept() method in a multiplexing fashion.

The server code Thelonius posted resolved that issue.

-David.