The Interactions pane isn't very useful when it comes to experimenting
with multi-threaded programs that rely on the wait/notify paradigm. Any
action that leads the main thread to sleep essentially freezes the
Interactions, unless there is some thread running in the background that
will eventually trigger a notify. So, ultimately, the only way to experiment
with the program is to revert to a batch-processing approach -- write a
"main" method (or an anonymous Thread object), then see what happens.
The Debugger provides a list of threads, and allows switching between
them during a debug session. I haven't used it much, and it's not obvious
to me how it might be put to good use. Clever use of breakpoints would
probably be required. I believe in this case it's still difficult to perform
on-the-fly experiments.
What I'd like to see is facilities to execute code in multiple threads on-
the-fly. For example:
- I define and connect a PipedReader and PipedWriter in the interactions
- I invoke the reader's read() method, then realize it's blocking, waiting
for input from the writer.
- I click a "new thread" button. There is some visual cue that I'm running
in a different thread (perhaps by using multiple tabs, by putting the
threads in a chooseable list, or by highlighting the "active thread" code
differently).
- I invoke the writer's write() method (I have access to the same scope as
the original thread at the time of thread creation)
- The original thread can now complete its evaluation, and I see the
output (in the other tab, or highlighted as "original thread" output)
- I switch back to the original thread (clicking on a tab or choosing from a
list) and continue my session
Logged In: YES
user_id=1075744
What do you think about the approach of creating a new
interactions pane per thread?