In AT&T SVR4 kernels, SCO, Solaris or other kernels that are hospitable to 
STREAMS, the bufcall callbacks are made at times when the OS knows that 
there is now memory available for STREAMS buffers, or when it knows that 
the finite pool of STREAMS buffers has been replenished.

The Linux kernel is not such an environment.  Consequently, LiS cannot make 
such intelligent choices as to when to call the callback functions.  What 
it does instead is call them based on a timeout that is fairly short in 
human terms but fairly slow in computer execution speed terms.

That is why you see the repeated unproductive calls to your retry routine.

-- Dave

At 08:41 PM 9/25/2002 Wednesday, Dick Farrell wrote:
>I am having a problem with memory allocation. I am using LiS 2.13.9 on
>RedHat Linux 7.2 (kernel 2.4.7-10).
>I think I am at least close to running
>out of memory, but when allocb() fails, I call bufcall()
>so that the allocb() will get retried when LiS thinks there is memory 
>available
>for it. The trouble is, the allocb() never succeeds, but bufcall keeps calling
>the callback routine which retries the allocb(), and on and on ...
>Could it be that bufcall thinks there is enough memory available, but the
>allocb() would still fail? Also, could bufcall return 0 in some cases, and if
>so, could the callback routine still be scheduled?
>
>I have attached the output of streams -s and streams -m.
>
>Thanks,
>Dick Farrell
>


_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Reply via email to