> If I remember correctly this discussion started because someone wanted an
> event-based (or something like that) API that would take care of the
> "charging hords"(?) problem that occurs whenever select returns because data
> is available, able to be written, etc and was monitoring multiple file
> handles. If this were done in user space would that take care of the CPU
> cycles semi-wasted and time lost looping through the file handles being
> monitored? Wouldn't the API simply be hiding the select call. It appears
> to me that the only efficient way of implementing an event based API would
> be if an assigned function in a user's program were called whenever data
> became available for a particular file handle being monitored. For example
> if a driver finished retrieving data from a device, in an efficient event
> based model, it would then call whatever function in a user space program
> was assigned to that event on that filehandle passing it the data so that it
> can be processed immediately or semi-immediately (having the function
> processed as soon as the process makes its way through the scheduler). And
> for this implementation I do not see how you could implement this in user
> space.
Yes, that was what this started with. Which is why what I was thinking
was a library
call that wrapped select (shoot the code for the wrapper is already in
Apache).
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/