Hi Michael!

On Nov 9,  7:17am, Michael Graff wrote:
> Subject: Re: pthreads in userland, signals, and itimer.
> "Dr. Lex Wennmacher" <wennmach@geo.Uni-Koeln.DE> writes:
>
> > I can very well understand your need for more timers and
> > signals. But I think just adding SIGTHREAD and thread timers is
> > suboptimal. We should be looking for a more general solution to the
> > problem.
>
> As do I, now.

Great!

>
> > A threading library would just issue this system call and get a
> > currently unused timer/signal pair, install a signal handler and set
> > the timer (in the usual fashion). Threading libraries share (the
> > new) timers with other libraries and applications.
>
> This will add a lot of new timers/signals, but I do see the need.
> I'll look into this idea.  I don't know how much of an impact it will
> have on things like context switches and the like, but in the case
> where no timers are allocated in this way things should be reasonably
> fast.
>
> Decisions to make:
>
> (1)  Should we have, say, 16 virtual and 16 real timers?  Or 8/8?
>      Remember that for each virtual timer there will be more work to
>      do at context switch time, and for each real timer there will be
>      an additional timeout in the kernel.

I'd suggest to go for 16/16 timers, 32 signals in the pool. This would use up
one __bits[] in struct sigset_t. The new system call could not only be used to
get itimer/signal number pairs, but also to get signal numbers for other events
(like, "send me a signal on an APM event"). So the signal pool should be >= the
number of timers.


> Alternate method:
>
> struct proc {
> 	...
> 	u_int16_t itimer_virtual;
> 	u_int16_t itimer_active;
> 	u_int16_t itimer_allocated;
> 	struct itimerval itimers[16];
> 	...
> };
>

struct proc {
        ...
        u_int32_t itimer_virtual;
        u_int32_t itimer_active;
        u_int32_t itimer_allocated;
        struct itimerval itimers_real[16];
        ...
};

The virtual timers are kept in struct pstats. This may enforce a hard split
16/16.

> Then, on each context switch, something like this:
>
> 	virtual_timers = itimer_virtual & itimer_active;
> 	for each bit set {
> 		check expiration.  If expired, signal.
> 	}
>
> The more I think about it, the more this bit probably makes sense.
>
> We could make this 32 instead of 16 more easily using the second
> method, I think...

Yes, I think that's the route to go ... Thank's Michael!

Lex