James Carlson wrote: > Glenn Fowler writes: > > On Thu, 27 Sep 2007 10:33:21 -0400 James Carlson wrote: [snip] > > re signal() in ksh/ast: the ast code uses signal() but it is intercepted > > at the library layer which uses sigaction/sigvec or whatever is available > > to coax usable signal semantics from the system implementation > > OK. As long as it's _not_ using the signal(3C) interface that's > exported by libc, I believe that this means that CR 6586967 should not > apply, so that shouldn't be the problem.
No, the issue doesn't apply... and at library symbol level the libast |signal()| interface is called |_ast_signal| to make sure we don't have something like a "namespace collision". > The problem was a defect in the way pending signals were handled > during a fork(2) when the caller established a self-resetting (old BSD > style) handler using signal(3C). In that one special case, the signal > handler was reset _before_ the signal was delivered, causing the > default signal to be taken. It's the source of the otherwise > mysterious "Alarm Clock" messages from dhcpagent. > > (No idea what a "hotfix" would be here, though. I didn't think > Solaris had such things.) Erm... AFAIK Sun has "hotfixes" (patch kernel at runtime) which can be applied to a live system... but that's only done in very very rare cases. I've abused the term "hotfix" a bit for the backport of a SIGCHLD handler patch to our ksh93-integration tree (see http://bugs.grommit.com/show_bug.cgi?id=311 ("Need hotfix for memory corruption")) because it was applied very late in the testing/putback cycle. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
