This does not happen on Linux, at least not when using Libc 5, without
undefining GNU or something like that. The GNU C library by default doesn't
interrupt the read or write call when the process receives a signal. Its a
nice feature, it allows me to leave out the error handling code that has to
take care of this problem on SunOS and others by restarting the same system
call; adjusted for any changes.
>> That's why I said win32... most apps have to target 95/98/NT these
>> days, so using the native kernel API isn't practical (it also
>
>With this being the linux-kernel mailing list, the native kernel API
>is of interest. Win32 and POSIX can be done in user-space, as calls
>to whatever the kernel API is.
>
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.
-
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/