Re: Multiple Threads in CLISP?

[Marcus Daniels <marcus@sysc.pdx.edu>]

>>>>> "Don" == Don Cohen <donc@ISI.EDU> writes:

me> LispView is not a reason to dive into this effort. 

Don> I don't recall ever mentioning lispview.

It was one concrete example of a potential win.  You didn't provide any.

me> Outside of ports of old software, and using IPC, I think the
me> remaining utility of threads doesn't make up for the large amount
me> of labor to make it happen.  

Don> I see much more utility than you
Don> seem to, and I hope that you're over estimating the cost.

There isn't just the cost in writing it. There is also the
cost in maintaining it, and the cost in the constraints it would
surely add to future enhancements (like in the performance area).
Similar arguments come up with makine C libraries thread-safe.

me> someone who really *wants* it should be the person to do
me> it

Don> I agree - the problem (I was hoping someone would suggest a
Don> solution) is how to combine what I think is more than adequate
Don> demand, and even willingness to expend effort, so as to get it
Don> done.  I'm afraid we'll need at least a little help from Bruno,
Don> who probably doesn't want to expend much effort.

What `we' would need is to start bumping into problems, and solving
them independently.  Supplication isn't going to help get it done.  :-)

me> I fear the `demand' for this feature is an artifact of
me> a dated and hopelessly deluded Lisp-centric view of the world.

Don> OK, I even accept that my view of the world is dated and
Don> lisp-centric.  But this feature is desired by many who do not
Don> suffer these afflictions.  I know of several threads packages for
Don> C, for heavens sakes!  (And if I know several there must be lots
Don> more.)

What are you doing that a event-based or callback-based IPC approach
won't cut it?  In this day and age of Linux and Windows 95 the
argument of expense just doesn't cut it.  And resource-wise, even a couple
of CLISP processes is still fairly small.

Don> I'll be happy to discuss technical reasons that threads are worth
Don> while.  Perhaps the mailing list isn't the best place, though.

The mailing list seems like a good place to me; just keep the subject
line accurate.

me> higher performance, maybe runtime code generation

Don> What's this about, and how does it relate to better performance?

I've got a portable package (so far for Sun and SGI) that writes
native code on the fly.  None of this ucky compile-to-C stuff.  I'm
looking at using it with CLISP.  An optional post-compiler, perhaps.
(having to worry about making the compiler, and potentially a
post-compiler worry about threads sounds like a pain).