Subject: Re: more siginfo q;s
To: enami tsugutomo <enami@but-b.or.jp>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 09/15/2003 00:53:41
On Sep 15,  1:46pm, enami@but-b.or.jp (enami tsugutomo) wrote:
-- Subject: Re: more siginfo q;s

| > | > +			kpsendsig(l, ksi, returnmask);
| > | > +			ksiginfo_del(p, ksi);
| > | > +			pool_put(&ksiginfo_pool, ksi);
| > | 
| > | Hmm, it looks like kpsendsig() may sleep but are you sure that bad
| > | thing won't occur?  (I don't know since I just read this diff through
| > | peephole).
| > 
| > What kind of bad thing you are thinking of?
| 
| It is ok you're sure that no other thread won't pick up the same ksi.

I see. It would be better to call ksiginfo_del() before calling kpsendsig()
| 
| > | > +	struct ksiginfo *ksi_next;
| > | > +	struct ksiginfo *ksi_prev;
| > | 
| > | Why needs to be doublly linked?
| > 
| > I had it a singly linked list, but I thought that the performance/storage
| > trade-off is better for the doubly linked list, specially for queued signals.
| If ksiginfo_get() is changed to remove an element when it is returned,
| single list is enough since ksiginfo_del() can be nuked.  And
| ksiginfo_save() can be written more straightforward.

That is a good idea. I will do that.

| Anyway, ksiginfo_del() need to update the head pointer if the element
| pointed by it is removed.
| 
| Also, you'are missing yamt's point (one of two); in ksiginfo_exithook,
| don't touch ksi->ksi_next once the ksi is passed to pool_put().

Ok, I will fix that too. Thanks for your help!

christos