Boost logo

Boost :

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 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 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at