| To: | bugzilla-daemon@xxxxxxxxxxx |
|---|---|
| Subject: | Re: [Bug 1104] New: signal delivery may lead to deadlock |
| From: | fche@xxxxxxxxxx (Frank Ch. Eigler) |
| Date: | Sat, 14 Feb 2015 20:28:15 -0500 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <bug-1104-835@xxxxxxxxxxxxxxxx/bugzilla/> (bugzilla-daemon@xxxxxxxxxxx's message of "Sat, 14 Feb 2015 20:22:30 +0000") |
| References: | <bug-1104-835@xxxxxxxxxxxxxxxx/bugzilla/> |
| User-agent: | Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
bugzilla-daemon@xxxxxxxxxxx writes: > [...] Frank has alluded to this in the past, see > http://oss.sgi.com/bugzilla/show_bug.cgi?id=1069, so I guess it is > time to go fix it, at least in this case. [...] Yeah, it's a textbook example. I was thinking at one point that the AF* functionality could be recast as something occurring synchronously rather than asynchronously. For example, we could define redefine the __pmAF* functions so that callbacks occur only as/after libpcp functions are about to return to the application. (A new __pmAFwait() could serve pmlogger's non-busy-looping.) Such an implementation of AF* could still rely on signals internally, but they'd just set a global flag for the deferred callback, and would thus be safe. - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Bug 1104] New: signal delivery may lead to deadlock, bugzilla-daemon |
|---|---|
| Next by Date: | Re: [pcp] datetime 'next TODAY', Ken McDonell |
| Previous by Thread: | [Bug 1104] New: signal delivery may lead to deadlock, bugzilla-daemon |
| Next by Thread: | Re: [pcp] [Bug 1104] New: signal delivery may lead to deadlock, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |