problem with RPC over SSL and concurrency

Hi list,

I have a constellation of communicating RPC services. Each is
implemented using Equeue cooperative threads. Within each service,
there is a single client connection to each other service with which
it must communicate, which is shared among the cooperative threads.
The Rpc_client and Rpc_transport modules seem to be designed for this
mode of use, and in fact this works fine over plain RPC. However, over
SSL I get exceptions that suggest unsafe concurrent access (e.g.
"#start_reading: already reading", among others).

Looking at Uq_ssl.ssl_mplex_ctrl, I see one thing that looks a bit
suspicious: In start_reading, we call nonblock_operation, which queues
a callback (using Unixqueue.once) that reads from the socket. But in
cancel_reading, we don't remove the callback. So if we start reading
and then cancel before the callback is called, it seems to me that the
read still happens, and when_done is possibly called twice (once from
cancel_reading and once from the start_reading action). Is this in
fact a bug?

Thanks,

Jake

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com