Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl

[Elf]

On Sun, 10 Aug 2008, John Cowan wrote:

> Elf scripsit:
>
> > you cant take the car or cdr of an atomic object: the slots dont exist.
>
> And yet in CL and all the way back to Lisp 1.5, (car nil) = (cdr nil) = nil.
> In pre-CL Lisps, the CDR of a symbol was its property list; CL finally
> abolished that.

[3]> (car 'foo)

*** - CAR: FOO is not a list

in clisp's implementation.  car and cdr did work, though.  the NIL is way,
way too overloaded in CL.


> > these arent relevant comparisons.  more relevant comparisons would be other
> > thread/concurrency systems: do any not allow threads to be killed?
>
> As I pointed out before, Java has deprecated suspend and terminate:
> http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

java's thread model has been broken from the start.  also note that its 
'deprecated' rather than 'removed'.

> Here's Microsoft's own discussion of why ThreadSuspend should
> not be used (except by debuggers that need to freeze threads so
> it can inspect their contents, something Scheme doesn't support):
> http://msdn.microsoft.com/en-us/library/ms686345(VS.85).aspx

actually, we do have breakpoints...


> Consequently, the .NET version is deprecated.  (Note that
> thread-terminate! is the same as a thread-suspend! that is never resumed,
> so one argument applies to both.)

TerminateThread is still in Vista, according to MSDN.

> POSIX threads have no suspend at all.  (Some implementations add it.)

i havent found a posix1003 implementation that DOESNT have it.
> Cygwin provides its own threading package, documented at
> http://www.navosha.com/ecos/c/cyg_thread.html .  The suspend and
> terminate functions are marked dangerous, for the same old reasons.

dangerous, yes.  deprecated/removed, no.  big difference.  the srfi marks 
them as dangerous as well, as does the chicken documentation.
> In short, everyone provides suspension for backward compatibility with their
> thread-naive definitions, everyone deprecates it or strongly discourages
> its use.  It is Considered Harmful.  It should go.

it is not 'Considered Harmful'.  its dangerous if used randomly.  the
functionality is still necessary.  furthermore, it should be possible to
create a threading model that would NOT leave processing in an inconsistent
state (and in fact i am working on such a thing). 
> > a more relevant comparison (and answer) might be 'why don't we get
> > rid of 'kill -9'?'
>
> Because there are very few shared resources between processes, and
> the kernel knows how to clean them up (with the exception of terminal
> settings).  Threads, by contrast, in principle share everything, and
> nobody knows how to clean up.

have you ever had mozilla (or firefox, or whatnot) crash?
and then run ipcs?
and had to clean up 3 or 4 shared memory segments and usually 1 or 2
semaphores by hand?


srfi-18 threads do NOT share everything.
and it is fairly easy to write code in such a way that any damage from 
termination etc is cleanup-able (or at least does not leave things in
an inconsistent state).  use your parameters.  call lambdas that create
threads with all the vars they can access.  use ports to communicate 
between threads.  its not that bloody difficult.

> > i dont think removing necessary, albeit dangerous (atm), functionality
> > is a good idea.
>
> Lispers spent decades thinking dynamic binding of lambda variables was
> necessary functionality even after they were finally convinced it was
> dangerous.  Part of what made Scheme revolutionary was that it threw
> that functionality away (and CL followed, breaking with the past).

what are you talking about?  fexprs?  im confused here.

-elf