pcp
[Top] [All Lists]

Re: [Bug 1104] New: signal delivery may lead to deadlock

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>