[boost] Re: async socket i/o [long]

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-13 23:07:36

Hi Michel,

> Ok the reason I expose it is for the possibility
> to write single threaded reactive servers.

I have written such using the library I proposed. The missing
ingredient is a function queue mechanism. I posted one to the list a
couple weeks ago, but feel that it is not technically a networking
thing. Of course, the network layer could be coupled to it in some
key places which would make things simpler to use.

The downside I see with a single-threaded server is that it can only
scale so far (even coded directly to select/epoll), because it can't
take advantage of multiple processors. So, in my mind I didn't
consider this style one on which to focus great concern for optimal
performance. For high performance, IMHO, you need a multi-threaded
solution.

> Both yes and no. An implementation such as
> active_event_dispatcher could provide this choice
> and functionality, at lower layer there should be
> implementations that let the user of the library
> make the choices (and even going reactive single
> threaded). And eg using iocp the threading is
> basically done by the os (just as long as you have
> a pool of thread dequeing packages). For the other
> notification mechanisms i guess a leader follower
> pattern should be implemented.

I have a hard time seeing why users should care, unless they have
grown up in this area and just want to know/control everything. As a
library user, I want to focus on my problems. Networking was
something I was forced into and have had to make the best of it<g>. I
wanted a library that did the right thing, did it efficiently and
offered me choices on how I wanted to know when operations were
complete. Some choices trade convenience for efficiency. Maybe I am
guilty of making this "simpler than possible" to paraphrase Einstein,
but I don't think so.

I see this like basic_string<>: it will make most of the people happy
most of the time. It will never be able to dislodge direct approaches
where portability is of little concern and absolutely optimal
performance is required. In such efforts, iostreams, FILE* and other
standard facilities start being eliminated as well in favor of native
API's (i.e., "down to the metal"). I think the times that this will
be necessary given my proposal will be very few. No library can
reasonably expect to be spared in the quest for optimal performance.
;)

> I think ut looks fairly good as well and agree whith
> calebs and have kind of don't like the extensive use
> of shared_ptr I think ownership and resource managment
> should be handed over to the user and not mandated by 
> the library.

I'm not totally in love with shared_ptr either, but it was a more or
less direct port from the original. The shared_ptr does bring a good
deal of inefficiency with it (though that is improving steadily). If
others feel the same, I will look at how to best do without.

Best,
Don

                
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail