Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: User vs. Kernel (was: To be smug, or not to be smug, that is the | Date | Thu, 21 Jan 1999 21:00:52 -0500 (EST) |
| |
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/
| |