3 ms·
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 di
by valarauca1 12y ago
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.
- waps 12y agoTechnically 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 12y agoI 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.
- Roboprog 12y agoAbout 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.