in reply to threads and leaking scalars

I've been trying a lot to find answers to these leaked scalar messages related to threads. I've given up. Life's too short. You shouldn't be getting them if your using "normal" (as in: non-XS) code, so you should consider them to be a bug in the threads::shared module.

However, I see you're using threads->yield(). In general I would say: don't. From the documentation:

threads->yield();
   This is a suggestion to the OS to let this thread
   yield CPU time to other threads.  What actually hap-
   pens is highly dependent upon the underlying thread
   implementation.
Furthermore from perlthrtut:

It is important to remember that yield() is only a hint to give up the CPU, it depends on your hardware, OS and threading libraries what actually happens. Therefore it is important to note that one should not build the scheduling of the threads around yield() calls. It might work on your platform but it won't work on another platform.

In my experience, under Linux yield() does nothing. So you're effectively burning all of your CPU in this loop:

while ( 1 ) { threads->yield; last if $thread_abort; next unless $thread_continue; ++$iter; }
I suggest you look at what you can do with lock(), cond_wait() and cond_signal() from threads::shared.

Hope this helps.

Liz

Update: added stuff about perlthrtut, which I guess should be in big, bold, red letters in the tutorial ;-)

Replies are listed 'Best First'.
Re: Re: threads and leaking scalars
by deliria (Chaplain) on Aug 04, 2003 at 12:20 UTC

    Well, at least I'm not doing anything wrong with passing the argument (: .. (i guess).

    Based on perlthrtut I got the impression threads->yield() was the way to go. I started using this function because a Bench i wrote gave me a 20% better performance, but on closer reflection my Benchmark was set up wrong.

    Thx, i'll have a look-see again at threads::shared