Christopher Kohlhoff <chris@kohlhoff.com> 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