[gambit-list] multithreaded debugging fun
Marc Feeley
feeley at iro.umontreal.ca
Wed May 20 09:29:36 EDT 2009
On 20-May-09, at 12:03 AM, lowly coder wrote:
> Please see typescript (sorry, copy/paste not working in X right now)
>
> i have test.scm, which forks off a thread (<thread #2>) which
> forever does:
> (pp 'yay); so I can see it print
> (+ "asdf" 1) ; just to generate an error
>
> I'm running gsc with -:dar, so i want debugging support, for all
> threads, and get thrown into a REPL when an error occurs.
>
> Here are my questions:
>
> 1) in my primordial thread, why do I have to execute some command
> (like "(void)") before I get thrown into the REPL in thread2? if
> everything is running concurrently, why does the error in thread2
> not pop up immediately and get me thrown into a REPL?
That's because, by default, the REPL's interaction channel is the
console and you have a single console. So all threads interacting
with the user (either REPL or calls to pp) are competing to get
control of this single console to do their interaction. A thread will
acquire the console on entry to the REPL and relinquish the console
when an expression is evaluated (most comma commands don't relinquish
the console). When the "acquire" operation succeeds and the thread is
different from the previous thread that acquired the console, a
message is displayed to indicate that the console is servicing the
REPL of a different thread.
The error doesn't immediately pop up because the primordial thread is
running a REPL, so it has acquired exclusive access to the console.
>
> 2) in thread 2, after hitting ,(c 0) ... why don' i immediately get
> an "yay"? (if it's continuing from that error, it should jump back
> to the (pp 'yay))
Because the other thread (primordial thread) was waiting to acquire
the console, and it acquired it at the moment thread 2 relinquished it.
>
> 3) after printing said 'yay', why do I have to hit (void) in the
> thread #1 before getting the error repl in thread 2? why doesn't the
> error immediately happen
Same as 2). The console is being multiplexed fairly between the two
threads that need to access it.
>
> 4) it seems like i'm ping-ponging between the two threads on the
> REPL. Is there anyway I can control this myself? (i.e. some command
> to jump me to thread1, some to jump me to thread2?)
You can use the ,(v #2) command to visit thread #2. But that's mainly
useful to interrupt a thread in mid execution.
The ideal solution is to use an IDE which can present to the user
several independent interaction windows. For example the Jazz IDE
(Jedi).
Alternatively, you can try the following "remote-debugging" code (for
Unix + X11) which will pop up a new xterm for each REPL. It is meant
as a proof of concept, so I'm not sure how much mileage you can get
out of it.
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remote-debugger.tar.gz
Type: application/x-gzip
Size: 3431 bytes
Desc: not available
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20090520/5f7f0545/attachment.bin>
-------------- next part --------------
More information about the Gambit-list
mailing list