Mail Archives: djgpp-workers/1999/05/02/07:23:07
On Thu, 29 Apr 1999, Alain Magloire wrote:
> For example when dealing with user threads a system call can not
> block the whole process/program. One way to deal with it
> is to take say read(), set the fd non-blocking, if the read() would
> block put the thread to sleep(the waiting queue) and set the handler
> for SIGIO or SIGPOLL, on receive of the signal select() will
> do the demux to see who is ready, and reschedule the threads base
> on whatever policy.
>
> Now I don't thing that notifying for an event can be done within
> DOS, Am I wrong ?
You are not wrong, unfortunately.
If threading is implemented with signals (e.g., setting a timer to
expire and having the scheduler be run from the handler for SIGALRM),
then the entire threading stops once you issue a DOS call, because
signal delivery in DJGPP is deferred until the program is back in
protected mode and touches some of its data (specifically, when it
accesses something in the normal DS or SS segments).
Using signals for threading is very attractive, because it is free
from many nasty limitations of the DPMI environment (a signal handler
is just a normal C function in DJGPP, so it can do anything). So the
only way I can think of for implementing non-blocking I/O is to
simulate it by breaking the request into several small chunks (but not
small enough to make the overhead of the DOS call be dominant). If
the I/O is not to a disk, but to some device, like the keyboard or
communications port, you could use `select' or some similar mechanism
in a special thread for polling the device with some small time-out to
avoid blocking the main thread. You could then raise SIGIO or SIGPOLL
from the thread that polls the device when the device becomes ready.
Of course, if threading is implemented by some other method, like
hooking some periodic interrupt, then you could do better with
non-blocking I/O. But then you will have a whole slew of nasty
problems on your hands, like DOS non-reentrancy, the fact that calling
DOS functions from the interrupt handler is a no-no, various DPMI-
related limitations, etc.
- Raw text -