[iolib-devel] Patches to make multiplexer use easier
Hello, Here are some patches that make it easier to just use the multiplexer object without having to go through the provided event loop/timer machinery. This is done in three steps: make the monitor/harvest etc. methods on multiplexer accept just file descriptors as well as FD-ENTRYs (note that I've only done that for epoll in this set of patches, others to come!), export the handler methods, and add an optional flags parameter to the MONITOR-FD method (really useful for epoll, the other backends I'm not sure about). Let me know what you think. I'd like to get these patches (or at least the equivalent functionality of being able to use the multiplexer without having to make FD-ENTRYs) into IOlib as I'm about to release some software that uses it. Thanks, Vladimir
Here's a corrected patch for 0005 that supersedes the one in my previous message. Vladimir 2009/11/16 Vladimir Sedach <vsedach@gmail.com>:
Hello,
Here are some patches that make it easier to just use the multiplexer object without having to go through the provided event loop/timer machinery. This is done in three steps: make the monitor/harvest etc. methods on multiplexer accept just file descriptors as well as FD-ENTRYs (note that I've only done that for epoll in this set of patches, others to come!), export the handler methods, and add an optional flags parameter to the MONITOR-FD method (really useful for epoll, the other backends I'm not sure about).
Let me know what you think. I'd like to get these patches (or at least the equivalent functionality of being able to use the multiplexer without having to make FD-ENTRYs) into IOlib as I'm about to release some software that uses it.
Thanks, Vladimir
Here's a patch that finishes adding the interface to the other multiplexer backends. Now it should be possible to use all of them for simple readiness notification on a set of integer fds. For example use, take a look at: http://github.com/vsedach/HTTP-DOHC Vladimir 2009/11/16 Vladimir Sedach <vsedach@gmail.com>:
Here's a corrected patch for 0005 that supersedes the one in my previous message.
Vladimir
2009/11/16 Vladimir Sedach <vsedach@gmail.com>:
Hello,
Here are some patches that make it easier to just use the multiplexer object without having to go through the provided event loop/timer machinery. This is done in three steps: make the monitor/harvest etc. methods on multiplexer accept just file descriptors as well as FD-ENTRYs (note that I've only done that for epoll in this set of patches, others to come!), export the handler methods, and add an optional flags parameter to the MONITOR-FD method (really useful for epoll, the other backends I'm not sure about).
Let me know what you think. I'd like to get these patches (or at least the equivalent functionality of being able to use the multiplexer without having to make FD-ENTRYs) into IOlib as I'm about to release some software that uses it.
Thanks, Vladimir
Stelian, any updates on this? Are you planning to apply these patches, or is there something you would like changed? Vladimir 2009/11/21 Vladimir Sedach <vsedach@gmail.com>:
Here's a patch that finishes adding the interface to the other multiplexer backends. Now it should be possible to use all of them for simple readiness notification on a set of integer fds.
For example use, take a look at: http://github.com/vsedach/HTTP-DOHC
Vladimir
2009/11/16 Vladimir Sedach <vsedach@gmail.com>:
Here's a corrected patch for 0005 that supersedes the one in my previous message.
Vladimir
2009/11/16 Vladimir Sedach <vsedach@gmail.com>:
Hello,
Here are some patches that make it easier to just use the multiplexer object without having to go through the provided event loop/timer machinery. This is done in three steps: make the monitor/harvest etc. methods on multiplexer accept just file descriptors as well as FD-ENTRYs (note that I've only done that for epoll in this set of patches, others to come!), export the handler methods, and add an optional flags parameter to the MONITOR-FD method (really useful for epoll, the other backends I'm not sure about).
Let me know what you think. I'd like to get these patches (or at least the equivalent functionality of being able to use the multiplexer without having to make FD-ENTRYs) into IOlib as I'm about to release some software that uses it.
Thanks, Vladimir
On Sun, 2009-12-06 at 17:23 -0500, Vladimir Sedach wrote:
Stelian, any updates on this? Are you planning to apply these patches, or is there something you would like changed?
I've merged your first patch(added readv too). As for the rest, I'm not inclined to merge them because ultimately I want the muxer to be callback-only and not to expose the details of the OS-specific mechanisms, which I consider to be only internals. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
As for the rest, I'm not inclined to merge them because ultimately I want the muxer to be callback-only and not to expose the details of the OS-specific mechanisms, which I consider to be only internals.
I don't mind the interface being based on callbacks instead of HARVEST-EVENTS, but I also don't see how the current interface is simpler or offers more than just exposing (UN)MONITOR-FD/UPDATE-FD/HARVEST-EVENTS and a generic mechanism to make a MULTIPLEXER. I don't get event-loop.lisp or why I would need it, and I definitely don't want synthetic timers in my networking code. Vladimir
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
_______________________________________________ IOLib-devel mailing list IOLib-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel
On 12/13/2009 12:52 AM, Vladimir Sedach wrote:
As for the rest, I'm not inclined to merge them because ultimately I want the muxer to be callback-only and not to expose the details of the OS-specific mechanisms, which I consider to be only internals.
I don't mind the interface being based on callbacks instead of HARVEST-EVENTS, but I also don't see how the current interface is simpler or offers more than just exposing (UN)MONITOR-FD/UPDATE-FD/HARVEST-EVENTS and a generic mechanism to make a MULTIPLEXER. I don't get event-loop.lisp or why I would need it, and I definitely don't want synthetic timers in my networking code.
It hides the fact that with epoll() you need to set/unset FD flags, while with kqueue() you add/remove, and select()/poll() have not state whatsoever. Furthermore, while for the moment only FD events and timers are supported, I'm planning to add at least two more: signals and file change notification. As for the timers, you're not forced to use them, although when working with the non-blocking sockets IMO they're essential. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
It hides the fact that with epoll() you need to set/unset FD flags, while with kqueue() you add/remove, and select()/poll() have not state whatsoever.
But that's exactly what the multiplexer abstracts.
Furthermore, while for the moment only FD events and timers are supported, I'm planning to add at least two more: signals and file change notification.
Ok, but I think I'm not the only person that just wants a portable interface to event-driven IO for sockets with minimal overhead.
As for the timers, you're not forced to use them, although when working with the non-blocking sockets IMO they're essential.
For HTTP servers it makes more sense to clean up any timed out connections in the server loop. I suspect that's the case with servers for most other protocols. Is there a difference for clients? Before we get any further, I'd like to see example code of how the event loop and timers work (documentation might help too). Maybe I'm misunderstanding something. Vladimir
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
_______________________________________________ IOLib-devel mailing list IOLib-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel
participants (3)
-
Stelian Ionescu -
Stelian Ionescu -
Vladimir Sedach