Hi Linus,
Please accept this patch for inclusion. The impact on the kernel is
negligible and it makes the kernel a bit more POSIX feature complete. I
have received good feedback from people who have used the patch and I have
used it a lot myself without any problems.
This patch should not impact processes not using POSIX timers. The pointer
to the array of POSIX timers is left NULL. Nothing is done. When the first
timer is created and when a clone with the TIMER_CLONE flag is called, the
timer overhead is created.
As a reaction to the question if this should be in the kernel in the first
place: IMHO, there is no way to emulate these calls in user space by using
the setitimer() system call. For the following reasons:
a. setitimer() sends only SIGALRM, POSIX timers can send any signal.
b. setitimer() does not know about overruns, POSIX timers do.
c. setitimer() can be used only once in a given process, you can have
up to 32 (configurable) POSIX timers at the same time in your process.
d. setitimer() cannot send extra information with its signal, POSIX timers
can send a si_value when using RT signals.
There have been no changes to the code for almost half a year now. The code
has been shown to work on UP and SMP on x86 platforms. There is (untested)
support for most other platforms. This support is just the addition of the
system calls to the architecture dependent tables.
The patch is attached to this mail.
The change relative to the previous version (2.4.0) is only that the patch
now applies cleanly to 2.4.1.
Test code and some other patches can be found on:
http://www.rhdv.cistron.nl/posix.html
Robert
--
Robert de Vries
[email protected]
Robert H. de Vries wrote:
> Hi Linus,
> c. setitimer() can be used only once in a given process, you can have
> up to 32 (configurable) POSIX timers at the same time in your process.
Why is there a limit? With such a small limit, any library that wants
to use its own private timers is going to have to agree a way to
multiplex with other libraries, and you're back to setitimer().
-- Jamie
On Sat, 3 Feb 2001, Jamie Lokier wrote:
> Robert H. de Vries wrote:
> > Hi Linus,
> > c. setitimer() can be used only once in a given process, you can have
> > up to 32 (configurable) POSIX timers at the same time in your process.
>
> Why is there a limit? With such a small limit, any library that wants
> to use its own private timers is going to have to agree a way to
> multiplex with other libraries, and you're back to setitimer().
There's a limit, simply because the thing is implemented as an array. Ugh.
It also doesn't handle the old itimers with the new ones, so you end up
having _both_ the three hardcoded timers _and_ the new timers. Which I
think is rather ugly.
Quite frankly, I'd much rather have the current real/prof/virt itimers
expanded to lists instead (ie _three_ lists: the behaviour of
real/prof/virt timers are very different, and trying to mix them on one
list would be horrible), with the magic timer ID value of zero being the
one that the old itimer() functions work on.
That way, CLONE_ITIMERS would also do something sane (which it doesn't do
with the current POSIX timer patch - it will clone the posix itimers but
not the old itimers).
Also note that the POSIX itimer patch with CLONE_ITIMERS seems to be
horribly buggy: it will save off "timer->it_process", but the process may
not actually EXIST any more by the time the timer is called: exiting only
decrements the usage count, which may be elevated due to clone's etc.
In short, there's not a way in hell I will apply this patch any time soon.
It has real implementation bugs that will cause oopses and
possible lockups (sending signals to non-existent tasks), and I think it
has design problems too.
Linus