Matt Dillon wrote:
> Umm. Terry, I really have no idea what you are talking about.
I am talking about being able to get the previous behaviour.
> What historical behavior? That FreeBSD was not properly
> dealing with SIG_IGN when every other UNIX does?
> So you are saying that your interest is in writing software
> that only works under FreeBSD? I'm sorry, I don't buy it.
If FreeBSD is not properly dealing with SIGCHLD (a premise
which I disagree with) , which is capable of being worked
around in the unmodified API, when is FreeBSD going to
correct it's assinine handling of SIGHUP delivery to group
leaders not resulting in it being sent to all processes in
the group because of incorrect order of revocation?
I don't have to check "read" return values on SVR4 or Solaris
to handle this case for things like "vi": these systems do
the _right_ thing, and send SIGHUP to all processes in the
group, and _then_ revoke the tty, instead of revoking the
tty, making all the children of the group leader group
leaders in their own right, and only delivering the signal
to the group leader itself, since the tty has been revoked,
so it's not the controlling tty with a HUP condition on it
for all the newly elected group leaders.
This _can't_ be worked around, without adding stupid checks
into all the code for things like tty's, which are never
supposed to generate EOF unless you ignore SIGHUP on purpose,
or are in cooked mode and type ^D.
> :At least with a SA_CLDWAIT flag, you could do the ignore and
> :you would get a compilation warning on half your programs (the
> :ones that used the now useless SA_NOCLDWAIT).
>
> Again, I have no idea what you are talking about here. Why
> would we want to introduce a non-standard flag?
I'm talking about obtaining pre-modification behaviour. And
if you will read the SUS2, you will see that you can introduce
any flag you please, and the programs are not supposed to
do anything with the flags they don't understand, since they
involve implementation defined behaviour.
This whole thing is about as stupid as supporting POSIX file
locking semantics "to be standard".
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
