Hi! On Sat, Jun 14, 2008 at 02:03:20PM -0400, Nick Mathewson wrote: >On Thu, Jun 12, 2008 at 07:59:45AM -0700, Teunis Peters wrote: >> I've not found any code to work with - but is there any reason that >> libevent would not work with standard files?
>> I keep getting permission denied >> more or less: >> fd = open(filename, O_RDONLY) >> event_set(&ev, EV_READ | EV_PERSIST, rd_callback, rd_data); >> event_add(&ev, NULL) >> -> EPERM >> Or does libevent only work with network connections? >Libevent uses underlying nonblocking IO mechanisms the platform gives >it. Some of these work well with non-socket file descriptors; some >don't. By default, libevent uses the fastest (best-scaling) backend >that it knows about for your platform, even if that backend doesn't >support all fds. >In the current svn trunk (which will eventually become libevent 2.0), >there's a feature to let you specify that you want a backend that >works with file descriptors, even if it doesn't scale well. On most OSes, however, checking for "readable" on plain files always immediately returns/yields a readable event anyway, so it's of no use (e.g. select/poll on Unix, I guess the same for epoll/kqueue, ok, kqueue differs from select/poll in that it returns readable if you're not at EOF, unless you set an additional flag, and then it returns in all cases). You have to use different mechanisms (like aio) if you want to hide disk latencies on plain files without using separate threads for their manipulation. So I think, using libevent events on plain files usually just doesn't make much sense in my eyes. Kind regards, Hannah. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
