Re: sigtimedwait with a zero timeout
James Antill wrote: > If you want to return imediatley (and there might not be data) the > answer given is usually... > > sigqueue( ... ); > sigwaitinfo( ... ); > > If the above will still schedule, then Linus might be more likely to > take a patch (I'd guess that he'd look at sigtimedwait() to be like > sleep() in most other cases though). If you mean that I can work around the problem by forcing a pending entry with a known tag and then poll with sigtimedwait/sigwaitinfo until I see this tag then it is doable, but I don't see the good in in this when a) sigtimedwait is documented in at least SUSV2 to return immediately with an error if the queue is emtpy and the timeout is zero b) As shown it is quite easily patchable (a simple if, and a few lines rearranged to fit the if) c) It is pure overhead, while the patch is close to no overhead: one added comparisation for the codepath when a timeout is selected, which in the context is nothing. -- Henrik Nordstrom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sigtimedwait with a zero timeout
Henrik Nordstrom <[EMAIL PROTECTED]> writes: > You are not late. In fact you are the first who have responded to my > linux-kernel messages at all. > > Yes, I am well aware of sigwaitinfo. > > sigwaitinfo blocks infinitely if there is no queued signals and is the > opposite of sigtimedwait with a zero timeout. Yes, sorry that's what I thought you wanted to do (Ie. you new some data was there and wanted to get it quickly). > sigwaitinfo is implemented as sigtimedwait with a NULL timeout which is > read as a timeout of MAX_SCHEDULE_TIMEOUT. Ahh I didn't know that. > sigtimedwait with a zero timeout are meant to be used by applications > needing to poll signal queues while doing other processing. Having > sigtimedwait always block for at least 10 ms can have a quite negative > impact on such applications. If you want to return imediatley (and there might not be data) the answer given is usually... sigqueue( ... ); sigwaitinfo( ... ); If the above will still schedule, then Linus might be more likely to take a patch (I'd guess that he'd look at sigtimedwait() to be like sleep() in most other cases though). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sigtimedwait with a zero timeout
You are not late. In fact you are the first who have responded to my linux-kernel messages at all. Yes, I am well aware of sigwaitinfo. sigwaitinfo blocks infinitely if there is no queued signals and is the opposite of sigtimedwait with a zero timeout. sigwaitinfo is implemented as sigtimedwait with a NULL timeout which is read as a timeout of MAX_SCHEDULE_TIMEOUT. sigtimedwait with a zero timeout are meant to be used by applications needing to poll signal queues while doing other processing. Having sigtimedwait always block for at least 10 ms can have a quite negative impact on such applications. Pleae note that the first version of my patch was quite broken. A corrected version was posted a few days later. Thanks for your interest. -- Henrik Nordstrom James Antill wrote: > > Henrik Nordstrom <[EMAIL PROTECTED]> writes: > > > Hi. > > > > While playing with signal queues it was discovered that sigtimedwait > > with a zero timeout apparently does block somewhat even if it should > > not. > > > > Why: > > > > It forces a schedule() > > This is a bit late (catching up with mail). But you know about > sigwaitinfo() yeh ? > > -- > James Antill -- [EMAIL PROTECTED] > "If we can't keep this sort of thing out of the kernel, we might as well > pack it up and go run Solaris." -- Larry McVoy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sigtimedwait with a zero timeout
Henrik Nordstrom [EMAIL PROTECTED] writes: You are not late. In fact you are the first who have responded to my linux-kernel messages at all. Yes, I am well aware of sigwaitinfo. sigwaitinfo blocks infinitely if there is no queued signals and is the opposite of sigtimedwait with a zero timeout. Yes, sorry that's what I thought you wanted to do (Ie. you new some data was there and wanted to get it quickly). sigwaitinfo is implemented as sigtimedwait with a NULL timeout which is read as a timeout of MAX_SCHEDULE_TIMEOUT. Ahh I didn't know that. sigtimedwait with a zero timeout are meant to be used by applications needing to poll signal queues while doing other processing. Having sigtimedwait always block for at least 10 ms can have a quite negative impact on such applications. If you want to return imediatley (and there might not be data) the answer given is usually... sigqueue( ... ); sigwaitinfo( ... ); If the above will still schedule, then Linus might be more likely to take a patch (I'd guess that he'd look at sigtimedwait() to be like sleep() in most other cases though). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sigtimedwait with a zero timeout
James Antill wrote: If you want to return imediatley (and there might not be data) the answer given is usually... sigqueue( ... ); sigwaitinfo( ... ); If the above will still schedule, then Linus might be more likely to take a patch (I'd guess that he'd look at sigtimedwait() to be like sleep() in most other cases though). If you mean that I can work around the problem by forcing a pending entry with a known tag and then poll with sigtimedwait/sigwaitinfo until I see this tag then it is doable, but I don't see the good in in this when a) sigtimedwait is documented in at least SUSV2 to return immediately with an error if the queue is emtpy and the timeout is zero b) As shown it is quite easily patchable (a simple if, and a few lines rearranged to fit the if) c) It is pure overhead, while the patch is close to no overhead: one added comparisation for the codepath when a timeout is selected, which in the context is nothing. -- Henrik Nordstrom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
sigtimedwait with a zero timeout
Hi.
While playing with signal queues it was discovered that sigtimedwait
with a zero timeout apparently does block somewhat even if it should
not.
Why:
It forces a schedule()
Also the actual delay seems to be at least 10msec more than requested,
but I guess that is an effect of the schedule()?
Attached is a small patch to optimize this case. (the .patchw version is
with -w to more clearly indicate the minimal changes made)
Some timings to prove the point: (Intel)
Linux-2.4.0-test7 without the patch:
timeout = 0 nsec: blocks for 10msec
timeout = 10 nsec: blocks for 20msec
Linux-2.4.0-test8 with the patch:
timeout = 0 nsec: does not block. ~0.1200 msec on my laptop.
timeout = 10 nsec: blocks for 20msec
Due to laziness I have not timed 2.4.0-test8 without the patch.
--
Henrik Nordstrom
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,15 +848,18 @@
timeout = (timespec_to_jiffies()
+ (ts.tv_sec || ts.tv_nsec));
- current->state = TASK_INTERRUPTIBLE;
- timeout = schedule_timeout(timeout);
+ if (timeout) {
+ current->state = TASK_INTERRUPTIBLE;
+ timeout = schedule_timeout(timeout);
- spin_lock_irq(>sigmask_lock);
- sig = dequeue_signal(, );
- current->blocked = oldblocked;
- recalc_sigpending(current);
- }
- spin_unlock_irq(>sigmask_lock);
+ spin_lock_irq(>sigmask_lock);
+ sig = dequeue_signal(, );
+ current->blocked = oldblocked;
+ recalc_sigpending(current);
+ spin_unlock_irq(>sigmask_lock);
+ }
+ } else
+ spin_unlock_irq(>sigmask_lock);
if (sig) {
ret = sig;
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,6 +848,7 @@
timeout = (timespec_to_jiffies()
+ (ts.tv_sec || ts.tv_nsec));
+ if (timeout) {
current->state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
@@ -855,7 +856,9 @@
sig = dequeue_signal(, );
current->blocked = oldblocked;
recalc_sigpending(current);
+ spin_unlock_irq(>sigmask_lock);
}
+ } else
spin_unlock_irq(>sigmask_lock);
if (sig) {
sigtimedwait with a zero timeout
Hi.
While playing with signal queues it was discovered that sigtimedwait
with a zero timeout apparently does block somewhat even if it should
not.
Why:
It forces a schedule()
Also the actual delay seems to be at least 10msec more than requested,
but I guess that is an effect of the schedule()?
Attached is a small patch to optimize this case. (the .patchw version is
with -w to more clearly indicate the minimal changes made)
Some timings to prove the point: (Intel)
Linux-2.4.0-test7 without the patch:
timeout = 0 nsec: blocks for 10msec
timeout = 10 nsec: blocks for 20msec
Linux-2.4.0-test8 with the patch:
timeout = 0 nsec: does not block. ~0.1200 msec on my laptop.
timeout = 10 nsec: blocks for 20msec
Due to laziness I have not timed 2.4.0-test8 without the patch.
--
Henrik Nordstrom
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,15 +848,18 @@
timeout = (timespec_to_jiffies(ts)
+ (ts.tv_sec || ts.tv_nsec));
- current-state = TASK_INTERRUPTIBLE;
- timeout = schedule_timeout(timeout);
+ if (timeout) {
+ current-state = TASK_INTERRUPTIBLE;
+ timeout = schedule_timeout(timeout);
- spin_lock_irq(current-sigmask_lock);
- sig = dequeue_signal(these, info);
- current-blocked = oldblocked;
- recalc_sigpending(current);
- }
- spin_unlock_irq(current-sigmask_lock);
+ spin_lock_irq(current-sigmask_lock);
+ sig = dequeue_signal(these, info);
+ current-blocked = oldblocked;
+ recalc_sigpending(current);
+ spin_unlock_irq(current-sigmask_lock);
+ }
+ } else
+ spin_unlock_irq(current-sigmask_lock);
if (sig) {
ret = sig;
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,6 +848,7 @@
timeout = (timespec_to_jiffies(ts)
+ (ts.tv_sec || ts.tv_nsec));
+ if (timeout) {
current-state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
@@ -855,7 +856,9 @@
sig = dequeue_signal(these, info);
current-blocked = oldblocked;
recalc_sigpending(current);
+ spin_unlock_irq(current-sigmask_lock);
}
+ } else
spin_unlock_irq(current-sigmask_lock);
if (sig) {
