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 <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
