Date: Sun, 2 May 1999 11:15:42 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Alain Magloire cc: djgpp-workers AT delorie DOT com Subject: Re: SIGIO non-blocking In-Reply-To: <199904291841.OAA04855@mccoy2.ECE.McGill.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.