Peter Wemm wrote: > > I think _sleeping_ is a problem, but allocation with M_WAITOK > > shouldn't be, given it's strange definition of "waiting". This > > is one of those hacks that John Baldwin was talking about earlier... > > As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if > you like". ie: it is a time bomb waiting for the right low memory condition > which will then explode with a 100% authentic crash or lock up. > > Pretend it said M_SLEEPOK instead of M_WAITOK.
M_WAIT became M_WAITOK. Unless M_SLEEPOK becomes M_SLEEP, I don't think it really matters: it's not going to wait indefinitely, like you'd want it to, so eventually, it's going to time out. You might get some big latencies along with some kernel printf's about inverted locks, but it shouldn't end up being fatal, like a real blocking wait would be, right? Or has M_WAITOK gone back to meaning M_WAIT, instead of M_WAIT_IF_YOU_FEEL_LIKE_IT_OTHERWISE_MAKE_ME_CHECK_FOR_NULL again? Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? -- Terry "Never solve a vast problem in a half-vast way" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message