Re: Design question

Hello

Thank You for the explanation. From docs,I've found that usually programs that use of some kind of 'watchers' on file descriptors may do either fork() or pthread() to process the event. In this scenario,I assume that once You call Your callback function,the application will block until it finishes the callback function ?

Basically,I need long-lasting TCP connection for a protocol that has kind of 'keepalive' messages integrated,for example if the server does not receive 'hello' packet from within the protocol in let's say 30 sec,the server will consider the connection closed. Occasionally,from the same connection/socket it might arrives some other commands that will demand some database operations against PostgreSQL database. I guess if this callback function will involve in any database operations it might block longer than they are supposed to,but on the other hand PostgreSQL API provides with asynchronous communication where You basically send some database command/sql and then watching that fd for any change meaning the backend send us a reply to our sql command ? Also as a addon to this scenario,some connection pooling application can be used (Pgbounder/Pgpool) that will increase the use of stored procedures/cached prepared statements and so,since cache is valid only if the database connection is operational.

Any ideas for this scenario ?  

Sincerely

Willy Tarreau wrote:
> On Mon, Apr 27, 2009 at 02:38:27PM +0200, Dragan Zubac wrote:
>
>> Hello
>>
>> 1. You said Your design is to use single-process event-driven
>> architecture. Could You just give some info about the design of backend
>> workers or callback that are called when an event occur ? Do You use
>> fork(),pthreads or something else to achieve concurency among things
>> that are supposed to be done at 'the-same-time' ?
>>
>
> an event-driven model consists in processing events as soon as they happen,
> and in very small and fast operations. For instance, it consists in reading
> data from a socket and storing it into a buffer, then calling a function to
> process those data. You should look around for more information about the
> "poll" system call and what is called "non-blocking I/O".
>
>
>> 2. Is You software capable to handle 'long-lasting' TCP connections,for
>> example far-end clients are supposed to connect to backend servers,they
>> need to keep those TCP sockets open for a long time,and occasionally
>> send/receive some data on those sockets ?
>>
>
> Yes, of course. You just have to configure large enough timeouts to ensure
> that connections will not be closed before your application speaks. What
> type of problem are you foreseeing with long-lasting TCP connections ?
>
> Regards,
> Willy
>
>
>
Received on 2009/05/03 13:51