Xref:	news2.mv.net comp.os.msdos.djgpp:1830
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
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:	<Pine DOT LNX DOT 3 DOT 91 DOT 960308053430 DOT 108B-100000 AT natalie DOT eee DOT upd DOT edu DOT ph>
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.

- Raw text -