Right now Python misses a wrapper for setitimer and getitimer and Ibelieve it would be interesting to include them. I'm (almost) sure someother people may find it useful too.I'm attaching a standalone module, but if it gets to be included inPython, I think it would be better to create a patch against signalmodule. 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 systemswhere it is available, and I agree that the signal module would be theright place.So whoever wants to complete it, feel free to produce a complete patchagainst the trunk.

Martin, thanks for supporting the idea.I'm attaching a patch. It is againstrev 61255, py3k branch.It patches configure, configure.in,Modules/signalmodule.c and pyconfig.h.inI wasn't sure if I should attach a diff for each file, so they are allpacked 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 topick this task, please say it.

I noticed that I forgot to change setitimer and getitimer functions fromitimer_setitimer to signal_setitimer (same for getitimer).I'm attaching a patch that should be applied after the previous one todo 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_FromDoublefails.* Do you have test and doc patches, too?* What does the "which" argument mean, is it an arbitrary integeridentifying 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. Ibelieve if you pass something else setitimer/getitimer might raise anerror (not tested).I still have to write doc and tests.

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

UpdatedDoc/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 easierto review that way.

Complete patch attached

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

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

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

Thanks for the patch. Committed asr61847 andr61848

Reopening. Apparently, the tests fail on FreeBSD; seehttp://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/builds/77/step-test/0Can you please look into this?

I'm investigating the problem loewis, thanks for reporting. But it wouldbe better if someone with running FreeBSD could help me there, in case Ifind 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 thattest."That is not what I get here, maybe a very different kernel, anyway, Ibelieve he could have mentioned this here.jeffrey.yasskin said:".. fix some flakiness in test_itimer_prof, which could detect that thetimer 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 reasonfor this changeand added:self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0)) -> this isthe same test I did for itimer_virtual, and it is a bit questionable itis really useful at all. I don't understand how these changes matcheswhat he comments on his commit.

FreeBSD's man page for setitimer/getitimer doesn't look different fromthe 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 notthe case in that machine. Both timers (virtual and prof) are set toexpire after 0.2 seconds, and for itimer_virtual it restarts the timer 3times before setting it to 0.If someone has a freebsd machine (a fast one apparently) that could runsome 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 hadchance to do some tests. The problem happens when Python is builtagainst or libc_r, or if you are using libmap you won't need torecompile 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 seemsvery similar to the problem related here.I've also done a very simple "test" in C, just to demonstrate that thisissue 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 calledand then the alarm is fired. Compiling against pthread, thr or nothing(since this example doesn't need any threading library) doesn'tdemonstrate 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 onhow to resolve this, besides saying to upgrade to FreeBSD 7 which useslibthr 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 toomit setitimer/getitimer on FreeBSD if the FreeBSD version is "wrong",either at configure time or at compile time. An even better solutionwould be to test at configure time whether these functions work, andrefuse 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. Seeissue 5722 for follow-up regarding FreeBSD functionality.