Re: [Gnuplot-py-users] thread.error: can't start new thread

[Ben W. <bw...@ma...>]

Ah!

Cheers, I did wonder if it was some thing like that. My guess is that 
changing the GnuPlot.py code would be quite involved and therefore 
beyond both my skill and available time.

Thanks for the quick answer!

Ben

On 03/01/2011 09:00 PM, Michael Haggerty wrote:
> On 03/01/2011 02:51 AM, Ben Whale wrote:
>> I'm not famliar with the inner workings of GnuPlot.py and am very
>> confused by an error I get. Anyone have an suggestions how I could avoid
>> it? Details below.
>>
>> Here's some sudo-code indicating how I'm using GnuPlot.py:
>>
>> g = GnuPlot.Gnuplot()
>> domain = calculate_function_domain()
>> time = 0
>> C = 1000000 #just a very large number
>> t = 0
>> while t<C:
>>       data = function(domain, t)
>>       p = Gnuplot.Data(domain,data)
>>       g.plot(p)
>>       time.sleep(0.01)
>>       t+=1 #just an example num
>>
>> This is the traceback for the error:
>>
>> Traceback (most recent call last):
>> [...]
>>     File "/usr/lib/python2.7/site-packages/Gnuplot/PlotItems.py", line
>> 485, in get_base_command_string
>>       fifo = _FIFOWriter(self.content, self.mode)
>>     File "/usr/lib/python2.7/site-packages/Gnuplot/PlotItems.py", line
>> 443, in __init__
>>       self.start()
>>     File "/usr/lib64/python2.7/threading.py", line 473, in start
>>       _start_new_thread(self.__bootstrap, ())
>> thread.error: can't start new thread
> Gnuplot.py us using fifos to write to gnuplot, and it does so by
> starting a thread for each Data object that is plotted.  (This could be
> improved, but that's how it works now...)  Each of these threads should
> die as soon as gnuplot is done reading the input from the corresponding
> FIFO.
>
> For some reason it is having trouble starting one of these threads.
> Assuming that the problem only occurs after many iterations of the loop,
> the most likely cause is that the process already has too many threads
> running and is therefore not allowed to start a new thread.  This, in
> turn, is probably because your loop is trying to write data to gnuplot
> faster than gnuplot can process them, and therefore many commands are
> backing up in gnuplot's stdin.  When the number of backed-up commands
> equals the number of allowed threads, BOOM.
>
> You could try increasing the sleep time between iterations, or somehow
> changing the Gnuplot.py code to limit the number of FIFO threads that
> are allowed to run at once.  In any case, you will have to find a way to
> prevent your program from getting so far ahead of gnuplot, otherwise
> even if threads don't run out, some other resource will.
>
> Michael
>