rwa@cs.AthabascaU.CA (Ross Alexander) (10/18/89)
ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1166@atha.AthabascaU.CA> [I, rwa] write: >>The really useful things you get out of job control are SIGURG, SIGIO, >>SIGSTOP, and SIGCONT. >Ah ha! Another nice reason for not doing job control. The signal() call >does not exist in POSIX. Instead there is something called sigaction(), >which uses bit maps. To conform to POSIX I need 15 signals, plus an extra >quasi-signal for detecting stack overflow in protected mode. Thus the >bit map is naturally an unsigned short, and is full. Job control would >mean going to longs for everything (or mediums--24 bits). Are you seriously proposing to let an accident of hardware implementation influence the OS design? C'mon, Dr. T., you're kidding, right ? And as for mediums, that's sort of a 1/2 solution. Offensive to everyone :-). I like the way 4.3BSD solves this one. The signal masks are of variable length - counted bitvectors, I think. SIGIO is something I wouldn't want to see lost - it's the thing that lets you write, for example, /bin/cu as a single process without needing the fork() hack used under classical v7. Given the performance of fork()'d processes under minix-ST (where I live, foax) I am fairly seriously interested in avoiding the need for two threads when dealing with a task involving asynch i/o (not _serial_ i/o, I mean i/o which is not synchronized to the programme flow-of-control). And of course busy-waiting is right out... Or instead, I'd be perfectly satisfied to avoid the whole thing and go to a multiple-lightweight-threads model of processes. What's good enough for Mach is good enough for me. After all, we've got such a thing in the kernel - let's export it up to user space, too. What think you? Ross