[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