Hi Robert, Thanks for contributing to these discussions! I hope that with you and the others involved we can get this long overdue library off the ground. Anyway, to respond to your question: --- Robert Ramey wrote:
The question here is:
Is aio.h interface not sufficient in some way? If not, what facility is it missing? If it is sufficient, then just depend on the available implementation or re-implement the interface in the most convenient way.
Robert Ramey
IMHO, the "io" part of "aio" is the primary thing what makes it insufficient. Unless I misread the man pages, I cannot post custom events or messages with aio; it is all about I/O on file descriptors. Which brings me to the other problem. At least on Windows, a file != socket != pipe != etc (regardless of the quasi-polymorphic WaitForXXX functions). If we constrain the discussion only to sockets, then this approach could be used. Sadly, pipes are a totally different ball game. If memory serves, the CygWin folks "mapped" all such types of objects to fd's, but doing so was very heavy handed. There was no other solution to their particular problem, but that is not the case here since we can invent the interface. The first issue is what spawned to Asynchronicity thread: given a general async mechanism, I/O could be easily adapted to it. The interface could be portable, even given the diverse ways and means necessary to achieve the goal. If we are to adopt an existing interface, I believe that it should be general enough for non-I/O uses. It should also be something that could be implemented on all platforms without undue inefficiency (something a select-style interface could not do, IMO, because of the poor performance of populating fd_set's or their moral equivalent). In a previous post I showed that the async technique I am proposing could be (fairly<g>) easily used to shield the application from library worker thread issues. With a little more work (and coupling), the use of channel.async_call could be encapsulated/automated to simplify the user experience. Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
I answer to Robert and Don in the same mail. Don G wrote:
[...] --- Robert Ramey wrote:
The question here is:
Is aio.h interface not sufficient in some way? If not, what facility is it missing? If it is sufficient, then just depend on the available implementation or re-implement the interface in the most convenient way.
We have a bit of the same problem as with a network library built upon I/O streams. There were many people who didn't feel comfortable with this idea because it doesn't map well. POSIX aio supports asynchronous reading and writing through aio_read() and aio_write(). Network developers probably expect some kind of aio_connect() and aio_accept(), too. But these functions do not exist as they don't make sense outside the network world. Either you force network developers to understand how to establish and accept connections asynchronously with the existing API (then you get a big discussion like this one: http://lists.freebsd.org/pipermail/freebsd-net/2004-October/005307.html :-) or you extend the API for a network library. Or you propose a better asynchronous API what Don did.
[...] The first issue is what spawned to Asynchronicity thread: given a general async mechanism, I/O could be easily adapted to it. The interface could be portable, even given the diverse ways and means necessary to achieve the goal.
I would be happy to create a network library while concentrating on asynchronous I/O. However I agree that it doesn't make sense if different libraries invent some kind of asynchronicity again and again - it would be nice to have one library for asynchronicity.
If we are to adopt an existing interface, I believe that it should be general enough for non-I/O uses. It should also be something that could be implemented on all platforms without undue inefficiency
I agree again.
In a previous post I showed that the async technique I am proposing could be (fairly<g>) easily used to shield the application from library worker thread issues. With a little more work (and coupling), the use of channel.async_call could be encapsulated/automated to simplify the user experience.
If I agree again I will tell you in the asynchronicity thread. :) I still have to look at your proposal with the nexus class in detail. Boris
Hi Don, Its been a while (Easter holiday/motorbikes/surfing). Lots of messages to chew through after a good break. There seems to be a lot of technical detail; platform specifics and implementation. All good but its really easy (for me) to lose sight of the ball. Some definitions; * asynchronous = absence of "blocking" calls in application code * I/O = exchange of data blocks between a process and and some part of the operating system * block stream = a sequence of data blocks; complete and orderly * manager = something that can be "opened" to initiate I/O and therefore processing of a block stream * controller = some entity within a process that is interested in a block stream and will therefore negotiate with a manager * 2-way block stream = simultaneous read and write (i.e. network connection) * codec = asynchronous coding and decoding of application data to and from a block stream (AKA marshalling, serialization) For me at least the major goals are prevention of blocking (asynchronous) and re-use of codec technology across all variants of block streams. Useful paths of discussion (IMO ;-)? * possible managers - winsock, filesystem * definition of interactions (between controllers and managers) open (controller -> manager) connected (controller <- manager) read (controller <- manager) read (controller <- manager) .. end (controller <- manager) * mechanisms for exchanging messages (i.e. as above) * should IPC mechanism (as above) be re-usable in other areas, i.e. not specific to asynchronicity? even pluggable? To help keep things murky.... I have implemented something with the above goals in mind. While thinking "pure async" I got fairly close but as others have pointed out the model for interaction WRT sockets manager does not overlay well onto the filesystem manager. Said another way - applying an async approach to what is normally sync processing of a file looks lame and unwieldy. But thats probably got more to do with the (dreaded) paradigm shift and is therefore not necessarily "wrong". Lastly, I have (re-)used the codec technology in sync operations, e.g.having received an async message across a network connection, in my responding state machine I sometimes record a new state image in a file with a single blocking call. What's with that!? Well either I was just being lazy or its perfectly valid to make such judgement calls. While expending great effort to remove blocking calls it doesnt mean that they are verboten. Confused? :-) Cheers, Scott ps: did mean to send to your new subject
Oops, a wee error below; ----- Original Message ----- From: "Scott Woods" <scottw@qbik.com> To: <boost@lists.boost.org> Sent: Thursday, March 31, 2005 5:20 PM Subject: Re: [boost] Re: Asynchronous I/O
Hi Don,
[snip]
* mechanisms for exchanging messages (i.e. as above) * should IPC mechanism (as above) be re-usable in other areas, i.e. not specific to asynchronicity? even pluggable?
This should not say "IPC" as the mechanism being referred to is intra-process. Cheers.
participants (3)
-
Boris -
Don G -
Scott Woods