On Thursday 07 August 2008 15:44:03 Felipe Magno de Almeida wrote:
.
On Thu, Aug 7, 2008 at 9:05 AM, dizzy <dizzy@roedu.net> 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@roedu.net "Linux is obsolete" -- AST