Re: esballoc() callbacks

From: Casper H.S. Dik (Casper.Dik_at_Sun.COM)
Date: 03/20/04 

Date: 20 Mar 2004 10:51:09 GMT

steve@moonglade.com (Steve Madsen) writes:

>Are there rules for sharing mutexes between a callback and the rest of
>the driver? (Aside from the STREAMS reentrancy issue discussed in the
>man page. I'm wondering about soft interrupt issues and how the free
>actually occurs.)

You should create the mutex as any driver mutex using the driver's
iblock cookie; that makes it "interrupt safe" (you can't be interrupted
while holding the mutex)

>I'm counting the number of buffers that haven't been freed yet and
>using the mutex to protect this counter and signal a condition
>variable when it goes to zero. Without this, a callback can occur
>after my state structure goes away, with the usual disastrous results.

>Is there any way to kick Solaris and get it to free these buffers? I
>have a run that has been sitting on an otherwise idle system for close
>to an hour now (no joke) with not a single buffer returned. I've seen
>other runs return buffers after a few minutes. I would expect these
>buffers to be returned to me soon after the transmit is complete, but
>this does not appear to be the case.

Streams messages are freed usin taskq's; in some cases earlier
tasks in the queue can block other tasks from executing.

But an hour doesn't seem right. Certain Solaris drivers use a similar
strategy and I think buffers going AWOL for a long amount of time
would not be expected behavior.

Casper 

-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Quantcast