Joe Pruett writes... > i just installed 2.3.2.1 on solaris 2.5.1 using gcc 2.8.0 and > immediately ran into a problem where the update task stopped being > invoked. a quick check with the debugger showed that UpdateDaemonPid > was non zero, but that process had exited, so it would never start a new > update task. poking around at the source i noticed that signal delivery > for children is not safe from interruption and upon further inspection i > notice that the code uses both sigaction and signal, sometimes one right > after the other. why? if sigaction is assumed to exist, then use it > for everything. that way you get safe delivery, automatic blocking, the > whole works. so, before i go make the code use sigaction everywhere, is > there a good reason why signal is still being used? There were a couple signal handling problems in the original code, the first being zombie nntpc's resulting from trying to flush stdout after a client disconnected, the second being SIGPIPE's getting raised after a client sent a QUIT and didn't wait for a reply. These are documented more thoroughly in messages 787 and 793. It didn't seem either polite nor prudent to make such a sweeping change without including the requisite support in the ./configure script to detect systems that didn't have sigaction. So I just made the smallest possible set of diffs that fixed the problem, and included #ifdef's to select between the old broken signal-based code or the new, working sigaction code. Those #ifdef's got removed in the 2.x tree (with my code being the branch included), so now if you don't have sigaction you are out of luck. But since the sigaction tainted code seems to have made it to "release" status after being a lowly patch and no one is complaining that nntpc doesn't compile anymore, I'd think you could pretty freely fix things up any way you choose without worrying about the ./configure support. -- nabil@kryten.spiritone.com http://www.spiritone.com/~nabil/
