#10 Hang on _FIFOWriter Thread on Method Access
After constructing a _FIFOFileItem using Data,
accessing _FIFOFileItem.get_base_command_string()
cause the program to hang, probably waiting on the
thread started in this code:
In "_FIFOFileItem.get_base_command_string":
fifo = _FIFOWriter(self.content, self.mode)
return gp.double_quote_string(fifo.filename)
In "_FIFOWriter.init":
...
threading.Thread.init(
self,
name=('FIFO Writer for %s' % (self.filename,)),
)
os.mkfifo(self.filename)
self.start()
As can be see, the reference to the 'fifo' object is
lost as _FIFOFileItem.get_base_command_string returns.
Running _Gnuplot.plot on this PlotItem, however, does
not cause the program to hang.
I'm fairly sure that this is not the expected behavior
for these FIFO based plot items, otherwise it makes it
difficult to extend their functionality with dealing
with threading headaches.
I'm running Gnuplot.py 1.8 on Python 2.5.2 on Ubuntu 8.04, but I suspect this bug would be present on any system which would set:
gp.GnuplotOpts.prefer_fifo_data=True
in the PlotItems.Data function
Attached is sample script which should cause the bug
if the above conditions are met.
Script Causing Thread Hang Bug
Logged In: YES
user_id=38106
Originator: NO
The thread that is started by _FIFOFileItem tries to write the data to one end of the named pipe, expecting the other end to be read by the main thread. The thread terminates as soon as the whole contents of the pipe have been read and the pipe closed, but not before that. Since you are not reading the data out of the pipe, the thread waits forever. Since the thread is not a daemon thread, Python will not exit as long as the thread is running. So the program hangs.
I don't understand why this is a problem. Normally there is nothing useful to do with a _FIFOFileItem except to plot the data that it generates, and if the data are plotted then the thread terminates as expected.
I suppose that one could change the _FIFOFileItem threads into daemon threads, so that the Python interpreter can end even if one of the threads is still alive. But it seems to be that using the _FIFOFileItem objects incorrectly will eventually cause problems anyway, so it is not so bad that the problem is obvious.
The fact that the fifo reference is not retained shouldn't be a problem, since it is a thread and therefore it won't be garbage collected while the thread is still running.
Please explain what you think should be different.
Logged In: YES
user_id=2099013
Originator: YES
Michael,
I guess I just don't understand the purpose of "get_base_command_string" method. I had originally intended to use the method to get a hold of the command string so that I could implement the gnuplot 'fit' command on the data that was referenced by the temporary file/FIFO/whatever, since in gnuplot, the 'fit' command's syntax is very close to that of the 'plot' command. Regardless of whether or not this was a sane plan on my part, the behavior of calling that method was entirely unexpected and it took me a while to trace the source. I had no idea at first that a FIFO was being created, nor should I have to care, right? It seems to me that such an interface method name should be free of odd threading side-effects, otherwise it would have been mangled. Respectfully,
-Craig