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
