[valarauca1]

Slightly unrelated, but this confused me.

>1139 (each of which causes a program reschedule)

I thought system calls were packaged into the binary itself and didn't necessarily cause a job to re-schedule. But just caused a context switch to take place, then execution continues.

I thought re-scheduling only happened on interrupt, or a thread reaching a blocked stated.

Could you clarify this for me, I'm interested.

[Roboprog]

About 10 years ago I remember prototyping some code on Linux with a perl script running a java program as a "coroutine" (er, service) via request/response pairs over a socket (not http). Then we moved it to AIX, where it was essentially unusable due to the lost time slice each time an IO sys call was made. On Linux, the remaining time slices were recovered and immediately used. On AIX, the time slice was simply lost until the next process scheduler tick. Ouch.

[waps]

Technically they cause a context-switch and a scheduler run upon return (I belive, not 100% sure), but you're right that does not necessarily result in getting put on the back of the work queue.

[valarauca1]

I think what might be the case is often so many system calls result in blocking events (I/O, IPC, etc.), its safe to assume a system call will block.