I think the sodopendfree() call in sodisconnect() can be either a) removed, or b) moved to the very end of soclose() (after sounlock())
uipc_socket.c Rev. 1.63 introduced the loaning code & thorpej@ sprinkled sodopendfree(). I see no strong reason why sodopendfree() has to be called from sodisconnect(). Anyway, thanks for this, I really enjoyed reading your analysis. :) On Thu, Jun 23, 2011 at 11:23 PM, Manuel Bouyer <bou...@antioche.eu.org> wrote: > On Thu, Jun 23, 2011 at 09:26:36AM +0200, Adam Hamsik wrote: >> [...] >> >> Wouldn't be workqueue be better solution ? No need to setup anything >> just create wq and use it where is it needed. > > I'm not familiar enough with workqueues. How well does it deal with > frequent calls (under heavy network load I guess this can be called > very often). What happens when the thread blocks, does this defer other, > unrelated workqueues ? > Also there is (from worqueue_enqueue(9)): > "The enqueued work will be processed in a thread context. A work must not > be enqueued again until the callback is called by the workqueue(9) frame- > work." > so it's not as easy as a persistent thread and cv_broadcast() ... > > -- > Manuel Bouyer <bou...@antioche.eu.org> > NetBSD: 26 ans d'experience feront toujours la difference > -- >
