Re: [Chicken-users] Segfault - a hard one

[F. Wittenberger]

Before we continue - isn't that too much of a discussion about a closed
case?

thread-terminate! in chicken works just fine now.

It properly cleans things up as it should.

To the best of my knowledge all it costs is about 10 lines of code.

If you don't need it, just don't use it.

Why flush working code and compatibility down the drain?


> At that point, we could no longer claim SRFI-18 compliance, but that's
> a very small price to pay. Just rename the unit `threads' or
> something. Maybe this is a change that can be made at Version 4?

Sooner or later there's going to be someone, who wants to run some
Scheme program, which needs srfi-18 including thread-terminate!  .
Then we'll see a document like this: "Runs with any SRFI-18 system.  If
you have chicken, please reverse-apply the svn diff from version x to
version y and build your patchycken.  This will run my-great-program too
without problems."  Next we need to invent the Farm Scheme system to put
a fence around our petchycken's and their coloured eggs.  --  That's not
exactly the world I would like to live in.  I'd say this is a price I'd
rather not want to pay.

Am Freitag, den 08.08.2008, 00:12 -0700 schrieb Vincent Manis:
> On 2008-Aug-7, at 19:53, John Cowan wrote:
> > 1) Run it in a separate process, which you can kill without damaging  
> > yourself.

This can easily cost several hundred separate process per HTTP request.
So I must regret.

But isn't just that run-and-kill (including cleanup) what
thread-terminate! is supposed to to - just internal to the thread
system.  So as a extreme case, an implementer might decide to run each
thread in a separate process (let's aside here how those will pass
values between threads), then thread-terminate! would translate into
kill(2).

So if a separate process and asynchronous kill is a valid alternative, I
would say thread-terminate! is equivalent.  It might just be cheaper.

> > 2) Use a modified version of "eval" to execute it that counts ticks.

Valid, but I'm unsure that I can do that.  Most code is compiled.  If
this modified "eval" needs to interact with compiled code we are exactly
back where we are: tell the tread system to change the continuation of
the victim thread to something to inform it about asynchronous reasons.