A guile story

[Neil Jerram]

You know that song about the gasman coming to call?  Here's a
guile-hacking story in similar vein.  Hopefully someone will find it
amusing, and there are details that you may like to comment on.

I was working on guile bindings for the Nokia 770's "hildon" API,
using guile-gnome.  These are more or less done, so I started
wondering about the best way to test them, and write applications
using them.  Writing code directly on the 770 is a bit sub-optimal, so
the best option IMO is to use Emacs on my laptop, with ange-ftp to
edit files on the 770.

That requires an FTP server on the 770.  I looked at a couple of
Debian packages, but for reasons I forget these turned out to be
tricky to port.  Then I found the "Scheme Untergrund" FTP server (in a
package called SUnet), and decided to port that to Guile.  150 lines
of compatibility code later - because SUnet is quite old and was
written for PLT - I think it's getting close to working.

The process was incremental: mostly just trying to run the code, get
an XXX undefined error, write the necessary compatibility code for
XXX, then try again.  But when I got as far as trying an "ls", the
server appeared to hang.  So then I thought, "I know, I'll use
guile-debugging to break at the start of the handle-list procedure and
then single step through the code, to see where it hangs."

I added the appropriate incantation to the FTP server's start up code
and set it going.  It ran like treacle, but eventually hit the
breakpoint and popped up the stack in Emacs - hooray!  Except that
when I then pressed space to single step... nothing happened.

I eventually narrowed this down to the interaction between calling
accept on the main FTP server thread at the same time as read on the
FTP data connection thread (which is where the breakpoint was hit).
At least, the problem was apparently fixed by inserting a select
before the accept, so that the accept never blocked.  I'm aware that
this problem has been reported before, and that someone prepared a
patch to fix it, but (i) I thought we had applied that patch, and (ii)
I thought the problem affected coop threads only, not pthreads.

What next?  Single stepping was now working, but the program keeps
going unbelievably slowly - e.g. a minute to execute a single
evaluation step.  From "top" I noticed that the program's memory usage
was 52M, and still steadily rising.

That's the latest position.  My guess is that the long periods where
nothing happens except CPU burning are huge GCs, and that some GC bug
affecting multiple threads means that these GCs never actually free
anything (or not as much as they should, anyway).  Any ideas or other
datapoints would be much appreciated.  Does the Boehm GC handle
multiple threads?  If it does, perhaps I should try out Ludovic's
BGC-Guile.

All in all, I feel like I've got quite a few problems to work through
first, in order to get back to testing those hildon bindings.

Thanks for reading!

     Neil