Uri Guttman wrote:
> you don't even need children to do non-blocking rpc calls. if you do the
> protocol yourself and it is over a socket (as it should be), you can do
> async rpc calls.
The protocol is my own and it can do async calls. However I do in fact
also use DBI. Otherwise I would probably be playing with Coro.pm in
combination with the async calls.
> but i won't assume anything since the OP has not given a full problem spec
Your description of apache as lightweight UI frontend and a perl
middleware server to do the heavy lifting is pretty much what I'm doing.
However the middleware server needs to make calls to some other backend
servers, some of which make DBI calls and ALSO call another backend
server. Yes, this is probably getting into the realm of expensive
commercial solutions but this is a zero budget project of mine and I
really want to believe that perl can handle it.
The specific problem I'm having with my current Thread::Pool solution is
that the server has to both select() to see if any new requests have
been sent, and also pump the pool for finished job results. So the
server loop boils down to:
while (1) {
($socket) = $clients_select->can_read(.1);
process($socket); # adds a job to the pool, to handle the RPC method
@ready = $pool->results;
}
But this makes the minimum round-trip time to handle an RPC call .1
seconds. Dropping the timeout on the select does decrease that minimum
RTT but of course increases CPU load.
Ideally I would do the socket writes (and maybe even reads) from the
threads so I wouldn't need to worry about worker thread return values,
but I can't figure out how to get a socket over to a worker thread since
Storable of course can't freeze a glob. But the threads live in the
same process so it should be possible somehow. I think threads::shared
can share a socket but I don't think that really helps when using
Thread::Pool.
I just realized that I should be able to use fileno() and new_from_fd()
to pass the fileno to the worker thread and reconstitute the socket
object there...
-- Jeremy
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
