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