Right now Python misses a wrapper for setitimer and getitimer and I
believe it would be interesting to include them. I'm (almost) sure some
other people may find it useful too.

I'm attaching a standalone module, but if it gets to be included in
Python, I think it would be better to create a patch against signal
module. Also, its tests are pretty poor. 

Improvements are welcomed.

I forgot to remove an unwanted comment from it =)
Attaching new version.

I can see nothing wrong with including setitimer support for systems
where it is available, and I agree that the signal module would be the
right place.

So whoever wants to complete it, feel free to produce a complete patch
against the trunk.

Martin, thanks for supporting the idea.

I'm attaching a patch. It is against rev 61255, py3k branch.
It patches configure, configure.in, Modules/signalmodule.c and pyconfig.h.in
I wasn't sure if I should attach a diff for each file, so they are all
packed in the same diff. Also, I wasn't sure if I should append the 
"configure" diff, but I did.

Documentation in "Doc/" and tests aren't done yet, if someone want to
pick this task, please say it.

I noticed that I forgot to change setitimer and getitimer functions from
itimer_setitimer to signal_setitimer (same for getitimer).

I'm attaching a patch that should be applied after the previous one to
do this renaming.

Patch review:
* ItimerError should be signal.ItimerError, not signal.error.
* It should probably inherit from EnvironmentError or IOError.
* itimer_retval will leak the new tuple if one of the PyFloat_FromDouble
fails.
* Do you have test and doc patches, too?
* What does the "which" argument mean, is it an arbitrary integer
identifying the timer?

Thanks for the review, corrections and suggestions Georg.

For the first three items: I will be working on this later today.

For the last item: "which" is one of those three new constants added. I
believe if you pass something else setitimer/getitimer might raise an
error (not tested).

I still have to write doc and tests.

I'm attaching another patch, this should be applied after the other ones
have been applied. It fixes what Georg mentioned. 
I have chosen to let ItimerError inherit from IOError, and improved the
docstring of setitimer.

Updated Doc/library/signal.rst, follows a patch.

I've done some tests for getitimer/setitimer, diff is attached.

Could you please put all changes in one complete patch? It's much easier
to review that way.

Complete patch attached

I'd like to also see this in 2.6. Should I update the patch (if it
doesn't apply) and test? (I guess the signal module hasn't changed that
much).

If you are going to backport it to 2.6, then the C wrapper should be
adapted to match Python 2.x C coding style. If the other parts don't
apply correctly, then you should update it aswell.

Okay, the patch applies just fine (besides configure, which must be
regenerated). Running the tests however consumes 3 gb of memory.
The range functions must be changed to xrange on trunk. I've also
changed the docs a bit ("new in 2.6").
I didn't change anything related to coding standards (is this an issue
with tabs vs spaces?).
all tests in test_signal work with a patched revision 61332 of trunk, on
a 64 bit linux.

Thanks for the patch. Committed as r61847 and r61848

Reopening. Apparently, the tests fail on FreeBSD; see

http://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/builds/77/step-test/0

Can you please look into this?

I'm investigating the problem loewis, thanks for reporting. But it would
be better if someone with running FreeBSD could help me there, in case I
find the cause for this.

Also some changes were made to the original patch:

neal.norwitz did a commit where he says:
"Using a negative time causes Linux to treat it as zero, so disable that
test."
That is not what I get here, maybe a very different kernel, anyway, I
believe he could have mentioned this here.

jeffrey.yasskin said:
".. fix some flakiness in test_itimer_prof, which could detect that the
timer had reached 0 before the signal arrived announcing that fact."

followed by these changes:

signal.setitimer(self.itimer, 0.2)        (old)
signal.setitimer(self.itimer, 0.2, 0.2)   (new) -> not sure the reason
for this change

and added:
self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0)) -> this is
the same test I did for itimer_virtual, and it is a bit questionable it
is really useful at all. I don't understand how these changes matches
what he comments on his commit.

FreeBSD's man page for setitimer/getitimer doesn't look different from
the one in Linux. 
But.. both tests assumes the computer is not so fast that it finishes
"for i in xrange(100000000)" before the timer expire, maybe it was not
the case in that machine. Both timers (virtual and prof) are set to
expire after 0.2 seconds, and for itimer_virtual it restarts the timer 3
times before setting it to 0.
If someone has a freebsd machine (a fast one apparently) that could run
some tests and help me on this, it would be very nice.

Also sorry for various typos in my last message.

Trent Nelson kindly gave me access to his FreeBSD 6.2 buildbot so I had
chance to do some tests. The problem happens when Python is built
against or libc_r, or if you are using libmap you won't need to
recompile but the problem still happens when using libc_r.

I started searching in the FreeBSD bug tracker and found this issue:
http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/49087 which seems
very similar to the problem related here.

I've also done a very simple "test" in C, just to demonstrate that this
issue isn't related to Python at all:

#include <stdio.h>
#include <signal.h>
#include <sys/time.h>

void h(int signo)
{
    struct itimerval t;

    getitimer(ITIMER_PROF, &t);
    printf("%d %d\n", t.it_value.tv_sec, t.it_value.tv_usec);

    printf("deactive ITIMER_PROF\n");
    t.it_value.tv_sec = 0;
    t.it_value.tv_usec = 0;
    setitimer(ITIMER_PROF, &t, &t);
}

int main(void)
{
    struct itimerval ival;

    ival.it_value.tv_sec = 1;
    ival.it_value.tv_usec = 0;
    ival.it_interval.tv_sec = 1;
    ival.it_interval.tv_usec = 0;

    signal(SIGPROF, h);
    printf("%d\n", setitimer(ITIMER_PROF, &ival, NULL));
    alarm(2);

    while (1) {
        getitimer(ITIMER_PROF, &ival);
        if (ival.it_value.tv_sec == 0 && ival.it_value.tv_usec == 0)
            break;
        }

    return 0;
}

When I compile this using -lc_r then the callback "h" is never called
and then the alarm is fired. Compiling against pthread, thr or nothing
(since this example doesn't need any threading library) doesn't
demonstrate this problem and all is fine (callback "h" is invoked,
infinite loop finishes and test returns 0).

Should further discussion be moved to python-dev ? I'm somewhat stuck on
how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
libthr by default.

> Should further discussion be moved to python-dev ? I'm somewhat stuck on
> how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
> libthr by default.

Discussing on python-dev is fine. An acceptable solution would be to
omit setitimer/getitimer on FreeBSD if the FreeBSD version is "wrong",
either at configure time or at compile time. An even better solution
would be to test at configure time whether these functions work, and
refuse to expose them if they don't (not sure whether that's possible,
though, as I don't know when the choice of threading library is made).

Closing this issue as the main functionality is committed. See issue 
5722 for follow-up regarding FreeBSD functionality.