Mailing List Archive

Steven Roberts writes:
> "Albert D. Cahalan" wrote:
>> Henrik Olsen writes:
>>>>> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>>>>>> Blocking system calls were a bad idea. Signals were added to unix
>>>>>> to address the lack of a general event queue. Since longjump won't
>>>>>> get you out of one of those crummy blocking system calls, some
>>>>>> fool made signals interrupt system calls. As a patch on top of
>>>>>> a patch on top of a patch, app programmers need to wrap system
>>>>>> calls in loops. Patching the brokenness even more, we see Netscape
>>>>>> talking to itself to get around a stupid race condition. Since
>>>>>> the unixy API does not support dispatching concurrent system calls,
>>>>>> someone added the aio_* functions to "fix" it for the limited case
>>>>>> of simple disk IO. All along the way people find hacks for their
>>>>>> own immediate problem rather than fixing the API.
> I personally like blocking system calls. They fit in far better
> for the application model I use. We have multiple threads,
> and it is easier to block. We in fact don't use the non blocking
> I/O calls in win32 because it is easier for us at least to use
> blocking ones. Yes, async IO can be nice for certain things, but
> saying blocking system calls are a bad idea is crap.
Don't tell me you _like_ interrupted system calls...
Threads change everything. How would you like a new thread
whenever a signal arrives? That could be an alternate fix.
>> If someone with great vision and design skills wants to create a
>> new API for Linux, we should seriously consider such a proposal.
> I think this kind of boils down to user vs. kernel API issues.
> why not great this all new wonderful API set in a user space lib?
Ha, ha, ha. NO.
As a prototype, maybe. It would be an extraordinary kludge.
It would have all the crappyness of user-space threads and worse.
> I really like that the
> kernel API in linux is small compared to the kernel API in win32. I
> quite a bit about the win32 API, but the most important thing I know, is
> that it is a big ugly mess, and I don't think linux should head in that
> direction.
No, the native NT kernel API is very simple. (it is not Win32)
> I still like the old principle, of if you can do it in user space, then
> do it in user space.
How about "do it in the best place" instead? Often that place is
a library, but don't get religious about it.
In this case, the kernel API itself could use some adjustments.
Emulating that in userspace is a sick joke.
-
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/

"Albert D. Cahalan" wrote:
> Steven Roberts writes:
> > I personally like blocking system calls. They fit in far better
> > for the application model I use. We have multiple threads,
> > and it is easier to block. We in fact don't use the non blocking
> > I/O calls in win32 because it is easier for us at least to use
> > blocking ones. Yes, async IO can be nice for certain things, but
> > saying blocking system calls are a bad idea is crap.
>
> Don't tell me you _like_ interrupted system calls...
>
> Threads change everything. How would you like a new thread
> whenever a signal arrives? That could be an alternate fix.
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 someone with great vision and design skills wants to create a
> >> new API for Linux, we should seriously consider such a proposal.
>
> > I think this kind of boils down to user vs. kernel API issues.
> > why not great this all new wonderful API set in a user space lib?
>
> Ha, ha, ha. NO.
>
> As a prototype, maybe. It would be an extraordinary kludge.
> It would have all the crappyness of user-space threads and worse.
>
> > I really like that the
> > kernel API in linux is small compared to the kernel API in win32. I
> > quite a bit about the win32 API, but the most important thing I know, is
> > that it is a big ugly mess, and I don't think linux should head in that
> > direction.
> No, the native NT kernel API is very simple. (it is not Win32)
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
isn't documented worth a damn -- best docs I have seen are from the
reverse engineering work from the sys internal's folks and the like)
>
> > I still like the old principle, of if you can do it in user space, then
> > do it in user space.
>
> How about "do it in the best place" instead? Often that place is
> a library, but don't get religious about it.
>
> In this case, the kernel API itself could use some adjustments.
> Emulating that in userspace is a sick joke.
Yes, if it does prove that it would be best in the kernel, then so be
it.
the best place principle is a good one, but I think if it is a tie
between user
and kernel, we should go user.
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/

Steven Roberts writes:
> "Albert D. Cahalan" wrote:
>> Steven Roberts writes:
>>> I personally like blocking system calls. They fit in far better
>>> for the application model I use. We have multiple threads,
>>> and it is easier to block. We in fact don't use the non blocking
>>> I/O calls in win32 because it is easier for us at least to use
>>> blocking ones. Yes, async IO can be nice for certain things, but
>>> saying blocking system calls are a bad idea is crap.
>>
>> Don't tell me you _like_ interrupted system calls...
>>
>> Threads change everything. How would you like a new thread
>> whenever a signal arrives? That could be an alternate fix.
>
> 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,
until you get it to work. This could happen because:
* Someone stops and continues the process
* There is an alarm timer event
* A child process exits
* The window size is changed
* You are running a profiler
...
You get gross code like this:
static void collect_data(int src){
int rcount;
int total = 0;
for(;;){
rcount = read(src,buf+total,AMOUNT-total-1);
if(rcount == -1){
if(errno == EINTR) continue;
perror("read() failed");
exit(1);
}
if(!rcount) break; /* done */
total += rcount;
buf[total] = '\0';
if(total==AMOUNT-1) break; /* 64 kB is more than enough! */
if(strstr(buf,"\r\n\r\n")) break;
if(strstr(buf,"\n\n")) break; /* broken unix-like client */
if(strstr(buf,"\r\r")) break; /* broken mac-like client */
}
}
>>> I really like that the kernel API in linux is small compared
>>> to the kernel API in win32. I quite a bit about the win32 API,
>>> but the most important thing I know, is that it is a big ugly
>>> mess, and I don't think linux should head in that direction.
>>
>> No, the native NT kernel API is very simple. (it is not Win32)
>
> 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.
-
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.
>> 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/

Anthony Barbachan wrote:
> 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.
There is a mechanism in Linux for this, added a few months ago.
See fcntl(fd, F_SETSIG, ...) and real time signals.
-- Jamie
-
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/

Anthony Barbachan wrote:
> >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.
good to hear. I hadn't experienced interupted system calls, but it's
been a bit since I've done any serious unix programming (will change
soon thankfully).
> 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/

Hi,
On Fri, Jan 22, 1999 at 01:15:42AM -0500, Anthony Barbachan wrote:
> >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.
What does it have to do with the C library? read() is a system call.
S.
--
If breastfeeding a pig is sickening to you, what the hell are you
doing on usenet? -- Aimee, on rec.music.tori-amos
-
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/

> > >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.
>
> What does it have to do with the C library? read() is a system call.
actually, read() is a wrapper for __read(), which is the system call
(glibc-2.0.7-29, RedHat 5.2).
--
Kevin L. Mitchell <klmitch@mit.edu>
------------------------- -. .---- --.. ..- -..- --------------------------
http://web.mit.edu/klmitch/www/ (PGP keys availiable from here)
RSA AE87D37D/1024: DE EA 1E 99 3F 2B F9 23 A0 D8 05 E0 6F BA B9 D2
DSS ED0DB34E/1024: D9BF 0E74 FDCB 43F5 C597 878F 9455 EC24 ED0D B34E
DH 2A2C31D4/2048: 1A77 4BA5 9E32 14AE 87DA 9FEC 7106 FC62 2A2C 31D4
-
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/

-----Original Message-----
From: Steve Dodd <dirk@loth.demon.co.uk>
To: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Date: Friday, January 22, 1999 9:24 PM
Subject: Re: User vs. Kernel (was: To be smug, or not to be smug, that is
the
>Hi,
>
>On Fri, Jan 22, 1999 at 01:15:42AM -0500, Anthony Barbachan wrote:
>
>> >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.
>
>What does it have to do with the C library? read() is a system call.
But its not called directly, the read function in the C library is called
first. Check the info docs on libc 5 (probably 6, but not sure) this change
in behavior is noted.
>
>S.
>
>--
>If breastfeeding a pig is sickening to you, what the hell are you
>doing on usenet? -- Aimee, on rec.music.tori-amos
>
>-
>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/
>
>
-
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/