sigtimedwait timeout

Henrik Nordstrom (hno@marasystems.com)
Sat, 24 Mar 2001 13:14:15 +0100


Noticed that my sigtimedwait timeout patch got into the kernel, so polled signal I/O should now
work much better.

The question on why the timeout is calculated with an +1 for non-zero timeouts is still open.
AFAICT is is not needed as timespec_to_jiffies() does a correct rounding. The effect now is

timeout sleeping
0 0
1ns 2 jiffies
1 jiffies 2 jiffies
2 jiffies 3 jiffies
3 jiffies 4 jiffies
...

If the "+1" is taken out then the timeout scale becomes the expected one, starting at 1 jiffie, not
2.

--
Henirk Nordstrom

Henrik Nordstrom wrote 22 September 2000:

> As I mentioned earlier sigtimedwait with a zero timeout (0,0) should not > block, but it currently does for 10msec (one jiffie). This is a > performance problem for applications using polled signal queues. SUSV2 > says specifically for this case "returns immediately with an error". > > Attached is a new version of my patch. The previous version messed up > the signal mask if the signal queue was empty and a zero timeout was > selected. > > It is still waiting one more jiffie than what is indicated by the > timeout value if other than zero, caused by the following code fragment: > > timeout = (timespec_to_jiffies(&ts) > + (ts.tv_sec || ts.tv_nsec)); > > Does anyone have any clue on why this +1 is there? I think this should > also go away to only read > > timeout = timespec_to_jiffies(&ts); > > -- > Henrik Nordstrom

[patch deleted]

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/