* De: Christos Zoulas <christos@zoulas.com> [ Data: 2002-12-01 ]
	[ Subjecte: Re: siginfo, signal queues, memory issues ]
> On Dec 1, 11:08am, jdolecek@netbsd.org (Jaromir Dolecek) wrote:
> -- Subject: Re: siginfo, signal queues, memory issues
> 
> | What do you mean? I agree that it should be possible to get
> | 'normal' signals queued, but I do not thing it should
> | be done by default, i.e. without SA_SIGINFO requested. Why
> | bother eating system resources for processes which don't
> | want the queing?
> 
> Because it is a pain in the ass to code properly. If you make
> two signal delivery paths, then how to you keep track of the
> delivery order?

Actually, this is easy enough to solve...  You deliver "fast"
signals from a sigset_t (or whatever) first, by popping them
off, as it were, as traditionally done, and your delivery
(not post) path is something like:

	int rv;
	struct ksiginfo *ksi;

	special cases to see if it is SIGKILL or whatnot

	rv = ksiginfo_create(&ksi); /* fills out p_pid and friends */
	if (rv == ENOMEM) {
		signal_fast(p, sig);
		return;
	}
	ksi->ksi_signo = sig;
	signal_send(p, ksi);

That's pretty much of a lie in terms of the important logic (how things
are factored out into different functions), but works well enough.

I don't have an implementation of this that I like yet, but probably
will (read: my conscience tells me to) add it before I look at pushing
such back into FreeBSD.
-- 
Juli Mallett <jmallett@NewGold.NET>