[ace-users] ACE_Reactor question
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Tue Oct 2 08:35:29 CDT 2007
Hi Valentin,
> Ok.It's my fault because I didn't detailed enough the
> problem.
>
> The HTTP server must deal with one client at a time.
Ok.
> While I'm serving one client I don't want the Acceptor
> to handle new connections by creating new
> service-handling object(RequestResponse_Handler
> objects in my case).
Right - and this won't happen as long as control isn't returned to the
reactor's event loop.
> I have
> class RequestResponse_Handler : public
> ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_MT_SYNCH> { ..}
>
> 1)This means that when a client connects
> RequestResponse_Handler::open() is called
> 2) When I receive the query string
> RequestResponse_Handler::handle_input() is called and
> the request is passed to thread #2 to do the hard
> work.
Ok, so this is a Half-Sync/Half-Async architecture, as described in
POSA2 <www.cs.wustl.edu/~schmidt/POSA/POSA2> and C++NPv2. BTW, if you
don't want the Reactor to accept another connection why are you passing
the request to a separate thread to do the work? It seems to me that
the easiest solution is simply to handle the request in the same thread
as the reactor..
> 3)At one moment in future thread #2 ends its work and puts the
> response in the sync queue of service-handling object with
> RequestResponse_Handler::putq(mb) 4)After that ::handle_output() &
> handle_close() is called.
This seems like a lot of extra overhead - why are you doing this?
> ONLY NOW(after step 4) I want the Acceptor to serve
> the next (buffered) TCP connection request by creating
> a new service-handling object(RequestResponse_Handler)
Ok, I see. First of all, this seems rather inefficient, but leaving
that aside, if you really want to do things this way why don't you
simply cal suspend_handler() on the acceptor handle in step 2?
take care,
Doug
More information about the Ace-users
mailing list