diff options
Diffstat (limited to 'open_issues/alarm_setitimer.mdwn')
| -rw-r--r-- | open_issues/alarm_setitimer.mdwn | 20 |
1 files changed, 7 insertions, 13 deletions
diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn index 34428586..5999808c 100644 --- a/open_issues/alarm_setitimer.mdwn +++ b/open_issues/alarm_setitimer.mdwn @@ -87,6 +87,10 @@ See also [[select]]. <youpi> bummer, we have broken ghc completely with the latest glibc patches <pinotree> youpi: what do you mean? <youpi> pinotree: it just hangs on installation + + +## IRC, freenode, #hurd, 2013-01-05 + <youpi> pinotree: it seems ghc was disturbed by the setitimer patch <youpi> pinotree: http://paste.debian.net/221807/ <youpi> pinotree: it seems to be simply due to nested locking of @@ -104,19 +108,9 @@ See also [[select]]. <youpi> I wonder whether it could be due to port set behavior being different from single reply port <youpi> I believe I understand what happens - <youpi> it's a know issue in select - <youpi> it's not interruptible by a SIGALRM for instance - <youpi> which is what ntpdate uses - <youpi> when __io_select is used, it *is* interruptible - <youpi> but when __mach_msg is used, it is *not* interruptible - <youpi> it happens that by luck, ntpdate uses just one fd, and thus it's - __io_select which is used, and thus it gets an interruption after 1s - (instead of after 60s, the timeout) - <youpi> with braunr's patch, it's __mach_msg which is used to wait, and - thus the interruption doesn't happen, and we have to wait 60s, the - timeout... - <youpi> so braunr's patch is still correct, it's the __mach_msg call which - we do need to make interruptible (it was already on the todolist) + +[[select_vs_signals]]. + <youpi> I'll rebuild ntpdate with a 1s timeout <youpi> that'll at least fix that <youpi> rah, no, doesn't work, it insists on getting its alarm |