Re: [boost] [asio]: extending asio

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-09-11 16:41:23

Christopher Kohlhoff <chris_at_[hidden]> writes:

> Andreas Pokorny wrote:
>> Hello,
>> 
>> I would like to add more asynchronous event sources to asio, like:
>> - input events for mouse, keyboard and joystick ..
>> - window exposure, move, resize events in some generic form,
>> - generic "quit" events
>> - file alteration
>> 
>> With directFB/X11/Unix/Linux most of that can be done directly through
>> select or epoll.
>> But since reading the message and parsing events is mostly done
>> by a third party library, I would only need the reactor part for these.
>> Is this possible with asio?
>> 
>> According to msdn it seems to be possible to create so called event
>> objects for direct input devices. I am no win32 expert so I do not know
>> if one can combine that with completion ports?

> Asio is not really intended for those use cases as, in general, user 
> interface events follow quite a different model to things like files and 
> sockets. If you want to integrate events from these sources the easiest 
> approach is probably to wait for them externally to asio and then use 
> io_service::post() to execute the handlers (or alternatively write a 
> custom asio service to do the same thing), but since you're not using 
> asio for anything else it doesn't seem worth it to me. You're welcome to 
> reuse any bits of asio that you find useful, though.

This issue is actually very serious and greatly limits the usability of
asio, nearly to the point of not being useful at all.  A Linux program
might want to communicate via some network sockets and pipes, handle
inotify notifications (an event structure is read from a file
descriptor), and perhaps use Xlib to communicate over a network socket
(which means Xlib must do the actual reading/writing, but not
necessarily the polling), all using only a single thread.

Currently, there is of course no way to do this with asio, and having
one thread for asio to do the network socket communication and another
thread with some other reactor implementation (like libevent) to do
everything else isn't very desirable, and it becomes preferable to just
not use asio at all.

It seems that one possible solution is to provide an interface for a
file descriptor reactor event source only on platforms that use a
reactor implementation internally (Unix platforms).

-- 
Jeremy Maitin-Shepard