> From: Hamish Mackenzie [mailto:[EMAIL PROTECTED]] > > I'll change the name to file_descriptor_set. The reason I had left it > > as socket_set was that I was not sure how to mix SOCKET and files > > on windows - but htat looks to be easy from your code.... > > Ah, I should have pointed out that I have only used file_descriptor_set > on sockets. I don't know if will work with win32 files.
There are (or were last time I looked) problems with select on files on windows. Can't recall the details. However, there are ways and means of working around this - I think cygwin has. > Also Hu Xinwei pointed out that fd_set should probably be an > implementation detail. Check out this for instance... > http://www.xmailserver.org/linux-patches/nio-improve.html We elected not to expose the fd set in our library. While we have not yet done so we wanted to be able to plug-in alternative "select-like" handlers such as /dev/poll and/or whatever worked on other platforms. The select (or whatever) lives in an event dispatcher (one per thread). We have active file descriptors (AFDs), 1 for read, 1 for write and 1 for except) which are merely thin facades sharing an underlying file descriptor holder (FDH) which is hidden from the user and provides most of the machinery around the real file descriptor. The AFD interface for async use is very simple/generic - just the ability to register a parameterless boost::function to be called when the AFD is ready. The base AFD class provides c-style read, write methods and the intent is that higher level code bind this lot together to provide appropriate interfaces eg. streambufs. There is also a method for registering/deregistering the AFDs interest in receiving ready events without having to create/destroy AFDs or deregister handler functions (obviously passed this down to the event dispatcher to update the fd set). > > Can we stick with SocketSetConcept and hide the fd_set completely. > > I like the idea of a boost event system that would allow waiting on > several types of events in a portable way. But I don't know if it is > feasible. See.. > > http://aspn.activestate.com/ASPN/Mail/Message/boost/1448661 I think it is, up to a point. How cross platform that point will be could be the real issue, though we have found that a huge variety of interfaces aren't really necessary. Some simple message passing method to allow things like async timers and shutdown requests can easily be extended. It is likely that almost any platform could support at least some form of "file" which can have a byte (makes partial writes impossible) written to it by any thread wishing to send an event to the reader of that "file". Once woken via this simple interface the reader can use whatever communication and synchronisation methods are appropriate (using the byte as a hint) to obtain additional information. > > If we can't have something like that then separating sockets and files > makes sense. Perhaps though we could add a socket_event_source_set (or > nicer name) that would work as I described event_source_set but would > only support socket_read_event_source, socket_write_event_source and > socket_except_event_source. It could be implemented using three > socket_sets and select. Are you describing what we called an event dispatcher? Regards Darryl Green. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
