[Openmcl-devel] recovering from a (break) in a thread

[Gary Byers]

On Wed, 2 Jun 2004, Lawrence E. Bakst wrote:

> I put a (break) in my code do some debugging.
>
> Is break broken wrt multiple threads in Version (Beta: Darwin) 0.14.2-p1!?

No.

>
> At 5:51 PM -0700 6/2/04, Lawrence E. Bakst wrote:
> > > Break in process OpenGL main thread(2):
> >> While executing: 2DGASKET::DISPLAY2-CB
> >
> >
> >;;;
> >;;; #<PROCESS OpenGL main thread(2) [Active] #x642ACFE> requires access to Shared Terminal Input
> >;;;
>
> So now what do I do? I tried ":Y 2" to try and yield to thread 2. Nada.
>

Try (:Y 2).

> I can't seem to figure out how :Y works or even if that's what is needed and I can't figure out how to resume my app.
>

Typing a :? at any prompt should show a short summary of the :-commands
available there.  Anything that takes a parameter needs to be parenthesized,
as in the "(:Y 2)" above.

> It's all weird because the listener, which I guess in my "main"
> thread, doesn't show a break level.

The listener thread isn't in a break loop.

> Does break stop execution of just the thread that executed it or all threads?

BREAK causes the calling thread to enter a break loop, as the loud intrusive
message above indicates.

At this point, the listener thread and the thread trying to enter the
break loop are both (logically) trying to read from the same input
stream.  In general, either of them could succeed (and read some or
all of whatever input was available), but which thread succeeded and
to what degree would be pretty arbitrary.

The model that OpenMCL follows is that the initial listener "owns"
the shared terminal input stream and can "yield" it (via (:y N))
to some other thread that might need it for relatively short periods.

This is certainly more cumbersome than the ideal solution (which somehow
infers the user's intent and causes input to always reliably be read
by the same thread and never forces the user to think about this.)  I
don't know how to implement that ideal solution; I think that any less
than ideal but implementable solution will require the user to be aware
of the issue.

The issue's discussed in some detail in:

<http://openmcl.clozure.com/Doc/background-terminal-input.html>


>  Any suggestions on how to debug, other than (format) would be
> appreciated.

It's certainly easier to use BREAK for debugging if the calling thread
doesn't have to wait for ownership of a shared input stream to be
transferred to it.  There are two approaches to this:

  1) Run the code that you're trying to debug in the initial thread.
If you're working on something derived from the GLUT example, you may
find that it's easier to debug if you run the GLUT event loop in the
initial thread.

  2) establish a window or network stream as the value of the background
thread's *TERMINAL-IO*.

> Is there any chance that (trace) would work into a
> thread?

TRACE doesn't typically try to read from an input stream, so it certainly
doesn't face the same issue that things like BREAK do.

>
> Best,
>
> leb
>