On Sun, May 03, 2009 at 01:51:17PM +0200, Dragan Zubac wrote:
> 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.
Normally not. This is the "easy but not recommended" way of polling file descriptors.
> In this scenario,I
> assume that once You call Your callback function,the application will
> block until it finishes the callback function ?
using fork/threads it would, but here with non-blocking I/O it will not. The application is notified by the system when there are I/O ready and the application then calls the function with that available I/O data. There is never a single blocking condition anywhere.
> 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 ?
you're too much focused on blocking mechanisms. Try to get that out of your head and thing non-blocking. Data are processed immediately, as soon as they reach the processs. You should even give it a try and run "strace" on the running process to see how it behaves. It will be more instructive than I can be.
Regards,
Willy
Received on 2009/05/03 20:36
This archive was generated by hypermail 2.2.0 : 2009/05/03 20:45 CEST