Hello Marc
I've tried your code from https://mercure.iro.umontreal.ca/pipermail/gambit-list/2009-June/003649.html
One problem I'm having with this is that hitting ctl-d (even once) will close the xterm. Also, on the new xterm the repl history from the previous instance is lost. Also, ctl-c doesn't work as it should (it makes the xterm go away instead of interrupting the program).
You're starting a proxy process inside the xterm which then connects back to Gambit using tcp and intermediates between the tty and the debuggee. Now maybe you did this for portability to windows, but on unix it should be possible to allocate a pseudo tty and just pass it's fd to the terminal emulator. urxvt (rxvt-unicode) has a "-pty-fd file_descriptor" option, and xterm has a "-Sccn" option which should do the same thing (the xterm man page is a bit confusing about that option and I haven't tried it yet).
So this would enable multithreaded debugging with only the master Gambit process running (debuggee = debugger), which should make it much simpler and more robust. But Gambit will have to accept multiple console ports; i.e. I'll have to instantiate a repl with it's own fd in the new threads, either as lexical closure or in a parameter object. Can you tell me how to make this work?
What I don't know yet is how signals (ctl-c) will behave, I guess all pty's will send the signals to Gambit, I don't know how to check which pty was responsible for a signal so as to map it back to the thread(s) which is(are) using that pty. I suppose there is some unix api for that.
Thanks, Christian.
Afficher les réponses par date