
On Thu, Aug 7, 2008 at 10:34 AM, dizzy <dizzy@roedu.net> wrote:
On Thursday 07 August 2008 15:44:03 Felipe Magno de Almeida wrote:
.
[snip]
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).
Exactly!
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
That seems necessary.
- have a basic_io_service<typename IOService> template relaying to IOService (this is what io_service already does)
My asio version (boost trunk) doesn't do this. It isn't templated at all. The impl_type typedef is changed at preprocessing time with the implementation type of the platform.
- update users that received io_service& to work with typename IOService& (this may be hard I haven't looked into it)
Well, io_service is better to work with because it can be used as a collection of io services, we need only one to deal with all IOs. If I use IOService instead, I'll be restricting to GUI events. [snip - suggestion based on templated basic_io_service] I think I should create a GUI-aware IOService. Though this works, it would probably have to be enabled explicitly through some kind of preprocessor symbol. It would be nicer if io_service could handle this automatically somehow. A io_service that *only* does name resolving for example could execute some of its thread pools in the thread that execute io_service::run for example. Reducing context-switches. [snip]
-- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST
Thanks, -- Felipe Magno de Almeida