Nicolas Williams wrote:
On Fri, Feb 23, 2007 at 12:30:07PM -0800, Anders Persson wrote:
There are many ways this could be done, for example, in BSD a single
callback function can be associated with a socket, which is triggered
whenever an event occurs on that socket. In addition, the user can
register a cookie, which in addition of a flag telling the user whether
it is OK sleep, will be passed in as an arguments when an event occur.
Although the BSD method should be enough, it might be nice to have an
interface that provides the user with a little more context. For
example, having multiple callback functions, each associated with a
particular event. Another possibility would be to have an event port
like interface.
Event ports could be the right way to do it -- and it seems that you
could adapt the code in uts/common/fs/portfs/port.c to be a kernel API
(most of the user-land APIs appear as static functions with vnode
arguments, except port_create(), which is a static that allocates a file
descriptor).
Right. I am planning to explore this venue a bit more.
Condition variables come close to good enough too, for an in-kernel
async socket I/O API, no?.
Maybe to some extent, but you would still need some sort of interface to
allow the user to wait for an event from a group of sockets.
Of course, given a callback interface like you describe the caller can
hook in whatever is best for them.
Thanks,
Anders
_______________________________________________
networking-discuss mailing list
[email protected]
