Hello! On Mon, Nov 28, 2005 at 07:27:34PM -0000, christopher baus wrote: >> Thank you, Its very interesting , because I'm using 2.6.5 kernel which >> does supports epoll , but every time I tried call a epoll_ctl with an >> ADD operation on the regular file , I get back a NOPERM errro back, so I >> was wondering if anybody succeeded before ( google not in much help :()
>Linux doesn't support non-blocking I/O on files. If you don't require >high throughput to disk your best bet is to use worker threads. This is >basically how squid handle's its disk cache. In fact that's what I do too, after handling I/O in the main program didn't work out well enough. Not exactly indeed. Instead we fork/exec off some number of helper processes (even with a little separate I/O helper binary) and talk a little protocol to them over unix domain sockets. They're fast enough so we don't do any shared memory hacks or similar. The main program is single threaded and uses some layers above libevent both for communication to clients etc. and to the helpers. We also have an alternative I/O model implemented using threads. Requests get sent via a locked queue and signalled using sem_post. The back channel is via a shared result queue and the "signal" is sent by writing a byte to an unnamed pipe, and the main thread waits on that using libevent, again. >If you are doing light disk writes your application might be able to get >away with blocking files because writes to the disk cache are basically >non-blocking. We thought that in our application too, but it didn't work out. Seems we write enough that too much will become dirty and writes will block, or we'll read things that aren't yet in the cache. So it makes sense that one request can outrun another one if the one arriving later can be serviced using the cache either on application or filesystem level. (The direct clients are multiplexed too, so they can take advantage of that, too.) Kind regards, Hannah. _______________________________________________ Libevent-users mailing list [email protected] http://monkey.org/mailman/listinfo/libevent-users
