Re: concurrent GC

[William.Lott@cs.cmu.edu]

Alessandro.Forin@SPICE.CS.CMU.EDU writes:
> That's the wrong way to do it on Mach.  You already have code that
> does it with the external pager interface, why would you want to be
> side-tracked by the people at Princeton that do not understand anything
> but BSD ? If you do not trust me, ask Rick Rashid which way it is 
> faster on Mach, he timed it.  Or look at /../testarossa/usr/af/tmp/appel
> for the program Appel and Rick used and time it yourself.

I'm not at all attached to any particular way of doing it.  If you say
an external pager is the way to go, then that is fine by me.

> > Is there anyway to control which thread gets interrupted when a signal is
> > delivered?
> 
> Yes, override the default exception handler and get exception messages
> yourself.  You can then forward all those you do not care about and
> get o'unix signals out of them if you want to.  I believe Morrisett
> has worked out things for SML, but you can look in
> /afs/cs/project/mach/src/bin/gdb/mach_os.c to see how GDB does it
> for Mach.  Look where it munges with the task's exception port
> and catch_exception_raise().

Does this work for all signals?  For example, if I use the kill system
call to send some random signal to the process, does it get mapped
into an exception first?

> But there are a kazillion ways in which Unix and multi-threading do not
> get along, signals are but one of them.  That is why I would strongly
> suggest you just forget about Unix if you want a parallel lisp and get
> down to Mach basics.

I'm happy with only allowing threads when under MACH.  I've used
several different pseudo-threads packages under C, and they have all
been a pain.  It's real annoying not being able to call read because
it will block the whole processes instead of just that thread.

> I would be delighted to explain to all the group how the logic behind
> the external pager facility works, and/or discuss the tradeoffs and
> why the Princeton people are wrong.  I strongly fear you might take
> the wrong design decision only because you have been explained the
> one way of doing it and not the other.

I guess I'll re-read all the external pager related man pages and the
stuff Chris wrote, and get you to fill in any blank spots.

-William