Re: mod_guile design problems

[Maciej Stachowiak <mstachow@viewlogic.com>]

Greg Badros wrote:
> 
> forcer <forcer@mindless.com> writes:
> 
> > Hmm.
> > How about a "Shared Memory Environment" guile environment type,
> > that is, an environment that resides in shared memory and can be
> > "docked to" from different processes? This might actually be a
> > nice idea for the standard guile distribution...
> 
> This would be super cool for writing Scwm modules, too-- I'd been
> dreaming about this for a while, but it seems pretty hard, but the
> payoff is great:  modules could still be written in Scheme, still have
> access to Scwm's data structures, but execute asynchronously in a
> pre-emptively scheduled second process (a bit nicer than the cooperative
> threads that Guile already has) that can crash and burn without killing
> the window manager.
> 

It seems to me that this model is not much better than pre-emptive OS-level
threads, but much more complex to implement*. A process that can scribble
into the Guile memory space can definitely screw it over pretty bad,
whether it is in the same process or not.

So I would rather see people expend effort on making Guile work with Posix
threads.

* You still need synchronization primitives, but they have to work
through your shared memory area - probably this means you need SysV IPC
even if you use mmap to create the shared area. You also have to worry
about distributed garbage collection (since different processes might
have references to the same data) and all sorts of stuff that a thread
model provides for free.

 - Maciej