[Rpm-devel] rpm-4.4.6 on solaris9-sparc64
fcusack at fcusack.com
Wed Jun 28 14:08:48 EDT 2006
On June 28, 2006 1:36:28 PM -0400 Jeff Johnson <n3npq.jbj at gmail.com> wrote:
> On Jun 28, 2006, at 1:07 PM, Frank Cusack wrote:
>> On June 28, 2006 10:50:49 AM -0400 Jeff Johnson <n3npq at mac.com> wrote:
>>> The issue is that SIGCHLD has delivery only to main thread.
>>> So if you put rpmlib on a thread, then rpm's internal lazy signal
>>> handler is per-thread, not
>>> and SIGCHLD is never delivered, so scripts never wake up. There
>>> are ways to instantiate the
>>> on the main thread, but do the ts.run() on a different thread,
>>> and there may well be additional
>>> on how the handlers are setup.
>> I didn't follow that, but having rpmlib on a different thread does not
>> affect whether or not SIGCHLD is delivered/handled. If there is a
>> handler, and at least one thread is not blocking the signal, it will
>> be delivered and handled.
> You are incorrect, the problem of thread not awakening at compl,etion of scriptlet was easily
> when the code was written 3+ years ago.
No, there is no way that a SIGCHLD is not being delivered when a child
process completes, if a thread is available to receive it. Whether or not
the intended thread is awaken is a different thing than what you've said
above (SIGCHLD not delivered), which is what I was arguing.
>> I can't tell if you're barking up the wrong tree here without looking
>> at the code, but I suspect the problem is that SIGCHLD is being posted
>> to the wrong thread and it isn't being taken into account that some
>> thread other than the one that starts scriptlets is receiving it.
> So look at the code rather than guessing, *please*.
Well, I was just trying to offer a suggestion of where you might look.
I thought given the misunderstanding with signal delivery and threads
that even some rambling (such as it is) might be helpful.
>> If that's the case, one fix (probably the cleanest, again, if what I'm
>> saying even makes sense considering I haven't looked at this code) is
>> simply to block SIGCHLD before doing anything else (importantly:
>> spawning any threads), then in ts.run() (I guess this starts the
>> scriptlets) do a blocking sigwait(). I assume ts.run() already just
>> blocks waiting for a pipe read.
> If you haven't looked at the code, you can't possibly understand the problem.
I don't claim to. I'm just offering an idea based on other stuff I've
read in this thread.
> And if you haven't tested the code, then any signakl fixing is suspect. Signal handlers are
> difficult to get correct,
I'd disagree with that. There are certain formulas you have to follow
for signal handlers (with additional rules for threads), but as long
as you stick to them it's fairly standard. For stuff like SIGCHLD,
More information about the Rpm-devel