Xref: news2.mv.net comp.os.msdos.djgpp:1830 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Multi-threads? Date: Fri, 08 Mar 1996 19:49:17 CST Organization: Rice University, Houston, Texas Lines: 38 Message-ID: <3140e39d.sandmann@clio.rice.edu> References: Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > I thought of a way to make this technique preemptive; that is, the > function lwp_switch () is actually set up as a signal handler for SIGALRM > or SIGVTALRM, then we use alarm () or setitimer () to "toggle" the > function at a regular rate. This is how I designed it to work. The setitimer stuff needs a little bit of work and cleanup, but the same core code is used for profiling and alarm, and was planned to be the heart of a scheduler which could handle tasking, too. Since __dpmi_int is called for virtually all swaps to system services, you could replace this in a scheduler too, if so desired. Yes, this was all discussed in the V2 design stages. > 1) is it possible for an alarm to be delivered in the middle of a library > or kernel call? that is, because MS-DOG is nonreentrant. I'm not sure how > the signal delivery mechanism works in DJGPP. SIGALRM (and SIGINT, and all other HW-interrupt based signals) are handled in a special manner, which schedules the signal to happen once the code is back executing in it's main path. This means that while the timer tick or keyboard interrupt which triggers the event happens in the middle of DOS or the BIOS, the actual SIGNAL is delayed until we are running in PM again. So you can lonjmp out of ANY signal, including SIGALRM and SIGINT. > 2) what is the resolution of the timer in setitimer ()? the timeval > structure has a tv_usec field, but exactly what is the effective > resolution of this thing? does DJGPP use the 18.2 Hz timer interrupt of > DOS, or is it reprogrammed to interrupt at a faster rate? It is 18.2 Hz by default. I have some hooks in the code which would allow the timer to be sped up (and still keep the correct DOS time) but it's not fully implemented. Since uclock() reprograms the timer to use mode 3 (I think, I don't remember exactly) these two routines need to know what each is doing to make them consistent. There is actually a general mechanism in V2 which allows HW interrupts to generate these deferred signals, but it's sort of complicated so I chose not to document it. Hint: it's in src/libc/go32/exceptn.S, and it must be called from assembler, since the argument is passed in a register.