Re: [boost] [asio]: extending asio

From: dizzy (dizzy_at_[hidden])
Date: 2008-08-07 09:34:46

On Thursday 07 August 2008 15:44:03 Felipe Magno de Almeida wrote:
> .
>
> On Thu, Aug 7, 2008 at 9:05 AM, dizzy <dizzy_at_[hidden]> wrote:
> > On Thursday 07 August 2008 14:26:23 Felipe Magno de Almeida wrote:
>
> [snip]
>
> > Of course it's cool but there are limitations given by the OS and the GUI
> > framework you use that do not allow that to happen. Do you have on all
> > asio supported platforms an OS system call that can wait for events
> > either from sockets or GUI? If so then you can do it (with some
> > modification on asio to allow extensibility at that level). If not then
> > you can't do it no matter how you design asio.
>
> I don't know about linux, but win32 can wait for IO completion ports
> on any thread, so while GUI has this limitation, AIOs wouldn't,
> so they could live happily ever after. ;).
> Am I missing anything?

OK I think I get it (finally). Although there still may be other solutions 
with whatever Win32 specific API (which I do not know since I'm more a POSIX 
programmer) you want the later solution I proposed but to be able to be done 
from within asio somehow. So you want io_service.run() to block in GUI event 
receiving but have an internal thread that blocks with whatever 
reactor/completion ports method for the events that asio usually handles 
(right now at least).

Interesting. Looking into io_service implementation it does not appear that 
generalizing io_service is very hard since it does seem to relay the 
functionality to a "service" type anyway (that is chosen depending on the 
platform). So what could be done is:
- define an IOService concept that should cover what io_service::impl_type 
does right now
- have a basic_io_service<typename IOService> template relaying to IOService 
(this is what io_service already does)
- update users that received io_service& to work with typename IOService& 
(this may be hard I haven't looked into it)
- typedef <whatever system I/O provider> SystemIOService; this is the platform 
based decision that asio makes right now into io_service definition
- typedef basic_io_service<SystemIOService> io_service;

This allows one to still use io_service as usual but if one wants to change 
the main event service provider he can write his own IOService type and 
instantiate basic_io_service on that (and this type can as you said create an 
internal thread that uses SystemIOService to wait and post asio normal events 
but in his own main code wait for GUI events). Since it's waiting for the GUI 
events in the thread that calls run() this should be (under certain 
situations) the same thread as the one that created the GUI windows.

If at least the modification that "io_service&" is taken as a template 
parameter is made then a faster solution than all those asio modifications is 
to make your own "io_service" type with similar API as asio's and require all 
async operations to go through your own io_service which will spawn an 
internal thread that uses an asio::io_service and blocks into its run() and 
will wrap every completion handler the user provided so that instead of 
actually calling the handler it post()s it on your own io_service event queue. 
So then when you block into your own io_service.run() you will handle either 
GUI events (which you wait for) or socket events which asio::io_service will 
catch and dispatch by posting them to your io_service.

Hope I'm not missing too much here :)

-- 
Mihai RUSU					Email: dizzy_at_[hidden]
			"Linux is obsolete" -- AST