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

[F. Wittenberger]

My two cents:

If chicken wants to be a practical Scheme system, as it claims on the
website, it should be possible to throw existing Scheme code on it and
have it run.  If the code is broken: garbage in, garbage out; stay bug
compatible.  If it can deal with the risks it takes: all is well.

Having to rewrite code for each Scheme system, because the particular
one does not support particular features is a burden and makes the code
messy.

Removing a procedure, which does whatever risky job it's supposed to do,
will make chicken an academic battle field, not a practical compiler.  

(Hey, I'm going to have a lot of such ideas!  How about immutable
strings and cons cells?  Eval - which basically always runs user
supplied code, since one would otherwise better have compiled it -
could, since it runs risky stuff, have additional arguments limiting
resource usage.  Or maybe the evals second argument could be used to
hold those restrictions.  No?  Then please let me use whatever low level
operations to implement these things.  I'm missing them.)

Am Samstag, den 09.08.2008, 00:27 +0200 schrieb felix winkelmann:
> On Sat, Aug 9, 2008 at 12:26 AM, John Cowan <address@hidden> wrote:
> > felix winkelmann scripsit:
> >
> >> 4) Make the worker thread check a global (or thread-local, but
> >> accessible from outside)
> >>   status and let it terminate itself.

I have a really hard time to understand what the difference is between
a) polling a variable from a level in between the Scheme system
(chicken) and the application code and
b) integrate that poll with the Scheme's threading system.

Especially since the latter already does the job anyway.

> The trouble is that it's running untrusted code.
> >
> 
> One shouldn't do that.

Could we stop here?  I'm looking at the case from an operating system
kind of view: being able to run untrusted code is just a requirement,
not something dispensable.

If those threads running untrusted code are unable to clean up after
themself, I can live with the restriction.  Similar to an OS closing
open file descriptors and the like, the threading system can/should
clean up those resources it cares about by definition, that is mutex's
and condition variables.  Everything else: see above note about garbage.

If one really needs additional clean up in threads: just don't
thread-terminate! them.  Send them a thread-signal! and thread-join!
them.  However this is not going to be enough: one would need to do
something to the exception handler, otherwise the application code could
loop there.  (But that's easy enough.)

/Jörg