Io Coroutines and Io Debuggers

Just read Jan-Paul's threads on the mailing list from 2011 about coroutines and Io debuggers.  Rather than necro both old threads, I thought I'd start a new one.

In reference to Jan-Paul's comment about coroutines causing unfortunate interactions with debugging and with Io exceptions - I just want to say maybe you should look at Iocaste: it is Io without coroutines.  Iocaste is a port (still in progress, but gaining stability and features) of the C implementation of Io to C++.

I think Io is a great language, and I understand Steve has reasons for using and advocating the implementation of coroutines that he has.  The idea of having coroutines that work not just at the Io level but also at the C level is surprising and interesting.  It's just that this doesn't align with, and in some ways works at cross purposes to, the things I wanted to use Io for (which is game programming with C++ and Io). 

I removed coroutines from Iocaste for approximately 4 reasons:

1.  Some of the low level facilities used by Io's implementation of coroutines are also needed by the C++ runtime for exception handling, and the two interact badly.  And by badly I mean that if you let a C++ exception and an Io coroutine cross each other on the stack, your application dies in the most horrible way imaginable.

2.  When these coroutines do go off in the weeds, the debugger (or at least gdb in Code::Blocks on my Mac with a recent gcc) somehow gets so confused it *can't even follow where the current instruction pointer went to*.  This isn't something that would normally happen using .

3.  Coroutines in Io provide concurrency, but not parallelism.  That is, they are an abstraction whereby one thread can do many things; they are not a way to make use of multiple cores.  I need the opposite:  parallelism, not concurrency.  Concurrent behavior of game objects is already implemented under the hood in the C++ game libraries I make use of.  I could benefit from multiple threads, but I must spin up multiple Io VMs to do that anyway.

4.  If I wanted to fix the crash problems, I could see three options.  If I made Io work like Stackless Python, I could reimplement coroutines at the vm level only.  But it would be a lot of work.  I could reimplement coroutines using real threads and a special GIL to schedule the threads like coroutines.  Less work but an ugly hack.  Or I could just take them out.  That was the easiest option and I haven't missed them - much.

However (and this in my mind is what ties the above topic together with Jan-Paul's other thread from 2011 about debuggers) it looks like Io's way of implementing a debugger is to have single-stepping turned on on a per-coroutine basis and send a message to another coroutine for each message processed.  Clearly I will have to modify that to make debugging work in Iocaste since it doesn't have separate coroutines.

First I want to ask if Jan-Paul (or anyone) made any progress resurrecting the Flux debugger.

I started a project a couple years ago - but it didn't go anywhere - to make a debugger that runs in a separate process and has 3D graphics built in (via Irrlicht and OpenGL).  That way it could be safe from crashes of the main process but might be able, for example, to examine the state of a mesh in OpenGL, even after the process that was building it crashed.

I've also been looking into trying to learn how to write a GDB plugin for debugging Io.  It would be really cool - and useful - if you could seamlessly single-step between C/C++ and Io code in an IDE like Code::Blocks.  I think it would be easier to write a Code::Blocks plugin instead of a gdb plugin, but I would need access to the running process's address space so I might need to be inside gdb for that.

Potentially either of the above two approaches could be adapted to be used by the existing C implementation of Io (you could just make an implemention of vmWillSendMessage to communicate with the Iocaste debugger from Io, over whatever channel the Iocaste debugger expects to receive the information).  It just wouldn't have the added advantage of being able to debug code when the C code running the Io vm is stopped.

For that matter, it will be tricky to make a debugger able to walk Io objects' slot from outside the Io vm without running any Io code inside the debugee to evaluate the values.  This would be tantamount to writing a debugger capable of debugging from the post-mortem core dump image of an Io VM's memory as well.  This could be a useful tool, but I suppose you could more easily make it single-step Io code to get the results of your variable watches too.  I suppose that's no worse than the situation where when you watch the value of a property in C# in the Visual Studio you have to make it run the property code to see the value.