Re: [clisp-list] more MT questions

[Vladimir T. <vtz...@gm...>]

On Sat, 21 Feb 2009 22:08:52 +0200, Don Cohen <don...@is...> wrote:

>
> It appears to me that after a thread finishes it remains un GC'd until
> it is killed.  Is there some reason threads don't get killed
> automatically when they complete?
> Also it seems odd that (list-threads) returns threads that can be GC'd.

After thread finishes it's lisp record will be colleted on next GC if there are no references to it.
list-threads return all threads that are not GC-ed (obviously all active + finished with references to them + some (if any) finished without references to them that will be collected on next GC).

> What does thread-active-p mean?  Just that it's not finished?

T means the thread is running, NIL - it has exitted. "running" means not exitted (it can be blocked in some system call).

> I had expected that while waiting for a lock it would be false, but
> it seems to be true.  For that matter it would be nice if the whostate
> were set to "waiting for <mutex-name>" while waiting for it.  This
> would perhaps be easier if mutex-name were defined.

thread-whostate is left to the user. Depending on the problem you solve - you better know what is your state.

> Can you give me some idea how to use thread-wait?  Also what it does?

It's not implemented and I am not sure that it will be. If somebody needs - he can be easily implemented it.
Polling over some predicate is not good idea with preemptive threads. 
There was discussion about this here: http://thread.gmane.org/gmane.lisp.clisp.general/12781.
both thread-state and thread-wait are not good if you do not have control over threads scheduler.

>
> I gather there's no notion of thread priority.
> Man pthreads seems to have something about scheduling policy and
> priority.

Yes there is no way to set thread priority. Should be added.

>
> What are exemptions about?

These are POSIX condition variables. Since in lisp "condition" means something different - Sam/Bruno in the past have chosen this name.

>
> I notice there's nothing about suspending/resuming threads.
> I guess it should be pretty easy to simulate with thread-interrupt.
> I tried
>  (thread-interrupt t1 (lambda()(catch 'resume (break "waiting to resume"))))
> which was pretty close to what I wanted, other than the fact that the
> console is then shared by two threads and you can't tell which is
> going to get the input you type.  I think there used to be a solution
> to this problem in which the debugger was connected to a separate
> input stream for each process and each such stream was connected to a
> separate emacs buffer.

suspend/resume of threads is not good and as you note - it can be easily implemented/simulated via thread-interrupt.
even with some mutex it will be better: (thread-interrupt thr #'mutex-lock some-already-locked-by-me-mutex)

Every thread can bind any special variable - including standard streams (from thread's function or via :initial-bindings). When the console streams are shared (default) - nothing good can be expected (as you noticed). 

>
> If you're going to support a whostate, then how about also
> (with-whostate state . forms)
> Although it seems a bit odd to support whostate when it seems nothing
> more than a special variable.  Or did you have in mind something else?
> In any case, for now you could define it as
>  (let ((*thread-whostate* state)) . forms)
> 

I am not sure it is supposed to be part of the threads package at all - since everybody can easily implement it as he wants and it's problem specific. With many problems "state" means more than just where the control is at the moment.