On Fri, 22 Jan 1999, Anthony Barbachan wrote:
> >> I guess I'm not sure what you mean by an interuppted system call then.
> >> in what cases will a read for example get interupted?
> >> I think I must be missing something (it's probably obvious, but I've
> >> been staring at way too much windows code today).
> >
> >If your process gets a signal, read() will return -1 and set
> >errno to EINTR. You must try the system call again, in a loop,
>
>
> 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.
Very nice, but sadly nonportable. Sounds like we need an all-Unix
conference to hash out an acceptable common solution, unless the majority
really, really loves writing #ifdef s.
> >> 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
If you do it with select(), yes.
> 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
VMS calls these ASTs, and every I/O function that could block accepts one.
This lets the application programmer definitively answer the question of
what to do with this I/O completion, instead of making the kernel guess.
It's a model I've come to appreciate, and if you'd rather be synchronous
you can call the blocking version (functionW() rather than function() )
instead. But the price of this is that I/O had to be designed as
fundamentally asynchronous, and a synchronizing mechanism had to be
provided for the less-critical but more numerous cases where you want to
block.
But this would require revamping much of the fundamentals of the I/O code,
and the result would be so un-Unixy that I don't expect to see it in Linux
anytime soon. Possibly the time would be better spent building a whole
new kernel that doesn't attempt to be Unix-alike, and go off in a
different direction.
> 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.
With ASTs you quickly learn to do as little as possible, like marking a
buffer reusable or moving it to another linked list, and letting the main
line do the heavy work. (I/O rundown gives the issuing process a priority
boost, so setting a flag and waking the mainline code gives pretty good
response, and if it's already running then there's no penalty.) Of course
there are exceptions.
And you're right -- it requires at least some support from the kernel.
Making sync. I/O appear to be async. is much more difficult in userspace
than the other way 'round. It's a question of keeping decisions close to
the information required to make them. The kernel knows best what the
devices are doing, and the application knows best what *it* is doing with
the results.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Innovation is only valuable if it improves one's life; otherwise it's
just one more silly change to cope with.
-
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/
> >> I guess I'm not sure what you mean by an interuppted system call then.
> >> in what cases will a read for example get interupted?
> >> I think I must be missing something (it's probably obvious, but I've
> >> been staring at way too much windows code today).
> >
> >If your process gets a signal, read() will return -1 and set
> >errno to EINTR. You must try the system call again, in a loop,
>
>
> 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.
Very nice, but sadly nonportable. Sounds like we need an all-Unix
conference to hash out an acceptable common solution, unless the majority
really, really loves writing #ifdef s.
> >> 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
If you do it with select(), yes.
> 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
VMS calls these ASTs, and every I/O function that could block accepts one.
This lets the application programmer definitively answer the question of
what to do with this I/O completion, instead of making the kernel guess.
It's a model I've come to appreciate, and if you'd rather be synchronous
you can call the blocking version (functionW() rather than function() )
instead. But the price of this is that I/O had to be designed as
fundamentally asynchronous, and a synchronizing mechanism had to be
provided for the less-critical but more numerous cases where you want to
block.
But this would require revamping much of the fundamentals of the I/O code,
and the result would be so un-Unixy that I don't expect to see it in Linux
anytime soon. Possibly the time would be better spent building a whole
new kernel that doesn't attempt to be Unix-alike, and go off in a
different direction.
> 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.
With ASTs you quickly learn to do as little as possible, like marking a
buffer reusable or moving it to another linked list, and letting the main
line do the heavy work. (I/O rundown gives the issuing process a priority
boost, so setting a flag and waking the mainline code gives pretty good
response, and if it's already running then there's no penalty.) Of course
there are exceptions.
And you're right -- it requires at least some support from the kernel.
Making sync. I/O appear to be async. is much more difficult in userspace
than the other way 'round. It's a question of keeping decisions close to
the information required to make them. The kernel knows best what the
devices are doing, and the application knows best what *it* is doing with
the results.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Innovation is only valuable if it improves one's life; otherwise it's
just one more silly change to cope with.
-
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/