Terry Lambert wrote:
> 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 conditi
> > 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
> again?
> Can we get rid of the NULL tests we had to put in when M_WAIT
> turned into M_WAITOK?

Umm, Terry, have you looked at the code?  We *only* have two wait states -
M_NOWAIT and M_WAITOK.  I dont care what it was ages ago, but in recent
history we have a single flag boolean flag.
M_WAITOK = 0x00, M_NOWAIT = 0x01. In spite of having two names, it is
really a single bit where M_WAITOK != M_NOWAIT.

M_WAIT for mbufs (not malloc) was an alias for M_WAITOK, and M_DONTWAIT
(also just for mbufs) was an alias for M_NOWAIT.

You call things and either permit them to tsleep() or you do not.

M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
"you must not tsleep!".  M_WAITOK conversely means that tsleep should be
called as needed.  Things like malloc still can return NULL even with M_WAITOK
for non-recoverable scenarios.

"All of this is for nothing if we don't go to the stars" - JMS/B5

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

Reply via email to