lkml.org 
[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: User vs. Kernel (was: To be smug, or not to be smug, that is the
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.040 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site