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