On Tue, Sep 17, 2013 at 4:15 PM, Joshua Lackey j...@thre.at wrote:
While it seems to work just fine in the simple example, my more
complicated program locked up after a few stop()/start()s. I decided that
tracking the problem with the temporary fix would be just as difficult.
(And
Hi Joshua,
You will be pleased to know that it still works even after leaving it for 5
minutes:
m@mi7:~/Downloads$ ./unconnect_test.py -h
Usage: unconnect_test.py: [options]
Options:
-h, --help show this help message and exit
-f Run failing test (with python sync_block) or passing
Hi again,
I forgot to press enter so the issue does happen on my end too:
m@mi7:~/Downloads$ time ./unconnect_test.py -f
my_sink: init 36995152
Running until enter is pressed: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work:
Hi Joshua,
For a temporary workaround, replace tb.lock() with:
tb.stop()
tb.wait()
...and replace tb.unlock() with:
tb.start()
This works for me:
pydev debugger: starting
my_sink: init 48050448
Running until enter is pressed: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
Yes, I did try that as a temporary fix.
While it seems to work just fine in the simple example, my more complicated
program locked up after a few stop()/start()s. I decided that tracking the
problem with the temporary fix would be just as difficult. (And ultimately
pointless when the problem
I can't get dynamic reconfiguration to work when my flow graph has a
sync_block implemented in Python. If I lock() and then disconnect() and
connect() other blocks, my program always hangs on the unlock(). It won't
even stop when I hit ctrl-c. Superficial debugging shows that a thread is
stuck
