Related to the idea of using file-change events on Linux: The file-change notification comes in the form of a signal. For some reason I cannot fathom, libevent doesn't dispatch signal events until some non-signal event is ready for dispatch. I see the problem in the code, but I am not sure if it was intentional or an oversight.
On the topic of thread-safety of signals: You can block signals that are watched by libevent and explicitly dispatch these signals with sigwait() instead of allowing the signal handler to be called. Alternatively, the signal handler could be extremely simple, like writing some data to a socket with sendmsg, without calling malloc or other thread-unsafe functions. The other end of the socket could be watched by libevent... On Monday, November 28, 2005, at 04:46AM, Alex Stapleton <[EMAIL PROTECTED]> wrote: > >On 28 Nov 2005, at 12:21, Richard Nyberg wrote: > >> At Mon, 28 Nov 2005 01:12:16 -0800 (PST), >> aleks sheynkman wrote: >>> Hi, all! >>> Does any know if I can use a libevent to manage regular file >>> desriptors (not a fifo). >> >> No. You can always read or write to regular files, so it doesn't >> really > >Er not true really, but anyway; what you appear to be looking for >aleks is the dnotify, or inotify API if your kernel supports it. That >does directory/file events under Linux. I've never used them my self >but Google should reveal more info. > >> make much sense. Other events for files that may exist in certain >> operating >> systems are not made available directly by libevent. >> > >_______________________________________________ >Libevent-users mailing list >[email protected] >http://monkey.org/mailman/listinfo/libevent-users > > _______________________________________________ Libevent-users mailing list [email protected] http://monkey.org/mailman/listinfo/libevent-users
