On Fri, 22 Sep 2000, Julian Elischer wrote:

> Throwing a lock in every structure is
> one
> thing but then to tie the whole bundle up together is a completely
> different ballgame.

        Yes, that's the hard part. It can be potentially dangerous to, for
  example, call the mbuf resource allocation code, while holding a mutex,
  and with M_WAIT. If the call goes in with M_DONTWAIT, then,
  theoretically, we shouldn't be blocking, so it's not so much of a big
  deal. However, for now, if you call with M_WAIT, you better make sure
  that you're not holding any mutexes going in. According to what I've been
  able to deduce thus far (and I really haven't looked much yet), BSD/OS
  seems to do this sort of thing as well (drop a lock on the socket before
  going in to fetch mbufs with M_WAIT). Their locking in the mbuf system
  seems less fine-grained than what I have so far (they lock the entire
  subsystem, effectively, when they're allocating mbufs and mclusters (same
        Archie Cobbs recently brought up the idea of writing a mbuf(9) man
  page which should eventually document, amongst numerous other things,
  when it's safe to be holding a mutex and when it isn't. As each subsystem
  will most likely have its own locks, it may be difficult to generalize it
        Bottom line: I do agree that we need such documentation, I just think
  that's it's difficult to do in a definitive set-in-stone way right now...
> -- 
>       __--_|\  Julian Elischer
>      /       \ [EMAIL PROTECTED]
>     (   OZ    ) World tour 2000
> ---> X_.---._/  presently in:  Perth
>             v

  Bosko Milekic

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to