Some of you may have noticed that there have been some changes brewing in
the libnal side of distcache to do with alternative I/O models. That's
nothing compared the shamb^L^L^L^L^Lwork I've got sitting uncommited in
my tree right now. But I've got to the point where I have to make a
fairly fundamental choice about how libnal should "work" at the API level
and so I wanted to ping the list. Even if you're not a libnal user at
all, I'd appreciate thoughts.
Right now, it's going to be possible to implement other types of sockets
and selectors, and being an employer of a network appliance company, the
reasons shouldn't be surprising. This should however allow libnal to be
*better* generalised in the software cases too, in particular allowing it
to fit nicely with poll(), epoll(), Win32, signal-based I/O, etc. Right
now, libnal does not at all fit well into those models.
What I'm doing for sure; NAL_CONNECTION and NAL_LISTENER objects are now
or will be bound (pointing to) a NAL_SELECTOR object, and depending on
the NAL_SELECTOR, that may be pointing back to the connections/listeners
too. This means that only NAL_***_add_to_selector() specifies the
selector, NAL_***_del_from_selector(), NAL_***_accept(), and NAL_***_io()
all have the selector removed from the prototype. It will be an error to
try and add an object to a selector if it's already bound to another -
you need to remove it first, so ***_add_to_selector() now has a non-void
return type. I've avoided using reference counts to support this binding
- it's assumed that if you "add" objects to a selector, destroy the
selector, and then try to do selector-related operations on those objects
(including removing them from the selector), then you're out of luck.
The question I have is how long this binding between a listener or
connection and the selector should live? One possibility is to have
things work the way they do right now, namely that when you "add" an
object to a selector, it applies for the next select operation only.
After that, the object is represented in the results but is no longer
bound for the next select - if you want to select on that object again
you should add it again. The other way to do this is to maintain the
binding from one select operation to the next, so that once you call
***_add_to_selector(), then (subject to the presence of data in
read/write buffers, etc) it will continue to be selected upon until it is
explicitly removed from the selector or destroyed. The benefit of this
approach is smaller code and lower overhead, but it's less select-like.
BTW: this is like comparing signal() (where the handler is reset after
handling a signal) and sigaction() (where the handler persists for a
signal type no matter how many times it arrives).
And while I'm scanning through the mail folder looking for past
announcements, what silliness do I find ...
On March 1, 2004 06:24 pm, Geoff Thorpe wrote:
> Right now, it's going to be possible to implement other types of
> sockets and selectors, and being an employer of a network appliance
> company, the reasons shouldn't be surprising. This should however allow
Yeah, like as if anyone actually believed it anyway. But still, to avoid
misunderstandings - s/employer/employee/ :-)