[gambit-list] multithreaded debugging fun
lowlycoder at huoyanjinjing.com
Sun May 24 15:25:20 EDT 2009
The following problem may be just a reflection of my poor programming
abilities, but I'm hope there's a good solution to this:
> (load "server.scm")
-- starts: (thread 2), (thread 3)
> ; back here at primordial thread
The primordial thread is to let me have an interactive REPL
thread 2 does actual work
thread 3 listens on socket 8080 for remote commands to execute (this is is
how I get vim/emacs to send commands to the repl, stuff like (load
"foo.scm")); this command is then executed inside thread 2; (so thread 3
practically never has any exceptions, even when foo.scm doesn't parse
The problem is -- foo.scm often has errors, either syntactical or run time
Thus, thread #2 throws an exception, and I have to deal with it in the
primordial thread, typically like
-- thread #1 --
-- thread #2 --
exception blah blah blah
> ,(c 0)
-- thread #1 --
Now, here's what I would like -- whenever thread 2 throws an exception, I
want thread 3 to get notified, and somehow resume it when a new file gets
loaded; however, if I don't load a new file, I want to be able to debug it
in the REPL.
thread 2 throws an exception:
I go to REPL, type (void) into thread #1, and debug it manually
I don't care about the exception, I'm in emacs/vim, I send another (load
"foo.scm") into thread 3, and thread 3 tells thread 2 to (a) resume and (b)
Anyone else run into this problem? How did you solve it?
On Wed, May 20, 2009 at 6:29 AM, Marc Feeley <feeley at iro.umontreal.ca>wrote:
> 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
>> (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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list