Re: [boost] [asio]: extending asio

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-08-11 20:05:44

On Thu, Aug 7, 2008 at 10:34 AM, dizzy <dizzy_at_[hidden]> 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_at_[hidden]
>                        "Linux is obsolete" -- AST

Thanks,
-- 
Felipe Magno de Almeida