[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Okay, I've incorporated the responses I've gotten from Rob and Chris.
> make-thread(function &key stack-size initially-suspended) => thread
> Creates a new thread that will initially call FUNCTION.
> Should have a :NAME arg. Probably :PLIST too.
> thread-self() => thread
> Return the thread object for the currently running thread. ### Make
> this a special instead?
> I'd say leave it as a function, though we might well want to implement it
> as a special reference.
> thread-exit(value) => nil
> Terminate the current thread. Acts as if the initial function return
> returned with VALUE. Unwind-protects *are* processed.
> ### Do we want to offer a facility to ignore unwind protects?
> I don't really think so. Common Lisp doesn't provide any way to sleaze out
> of unwind protects. If someone really needs to do it, they can grab the
> Mach thread and do the appropriate syscall.
> A note about thread values. If this mechanism is really going to see much
> use, then it would be nice if it supported multiple values. If it would be
> too complicated, we can blow it off, but all of the analogous mechanisms in
> CL allow multiple values. It would seem that thread creation is a
> sufficiently expensive process, that automatically bundling return values
> into a list wouldn't be prohibitively expensive.
Okay. I changed ``thread-exit-value'' to ``thread-results'' to make the
mv-ness more obvious. Besides, I never liked the name thread-exit-value.
> There seems to be a missing operation here, too. There is no way to
> iterate over all the threads.
do-threads((var &optional result-form) &body body)
> thread-suspend(thread) => boolean
> thread-restart(thread) => boolean
> What is the meaning of these return values? A success code? That isn't
> very Lispy. Would these operations normally ever fail if the program
> wasn't broken?
I don't remember what I was thinking then. Okay, no return value.
> thread-kill(thread) => boolean
> Zot the thread. ### what about unwind-protects?
> Well, that is an interesting question. My guess is that this operation (or
> at least some operation) should just blow the sucker away, since we need
> some sort of mechanism for nuking wedged threads.
How about an optional process-unwind-protects?
> But it seems that we also need some process control operations not in
> cthreads. For example, THREAD-DEBUG, which invokes the debugger on a
> thread (stopping it.) And perhaps THREAD-SIGNAL, which would signal an
> arbitrary condition in another thread. Maybe also THREAD-RESTART, which
> invoke a restart case. The debugger will also need internal primitives for
> picking apart the state of stopped threads.
I haven't put much though into this area, but I assumed that we would have
to have something along those lines also. I figure the first step is
getting the underlying support.
> make-mutex(&optional name)
> Create a new (unlocked) mutex.
> When designing new interfaces, I have a rule to always use keyword args
> over optionals unless it is blindingly obvious that the function will
> never want any new arguments. At least to me, it is not blindingly obvious
> here. For example, we might want to add a :DEBUG option that tells the
> system to keep track of more information, such as which thread has it
> locked, and to do more error checking.
Okay, the name is a keyword.
> Attempt to lock the mutex, and block until you can. Note: no attempt
> is made to protect against the case of a single thread attempting to
> lock a single mutex twice (which will deadlock it).
> Is there some reason why this error check is not possible? If it is
> possible, then should at least have a debugging mode that does the error
> check. [Ditto for MUTEX-UNLOCK]
There is no reason my it can't be done, but there are two reasons by I
don't want it done: it is not necessarily an error, and it would slow it
down. There are some synchronization paradigms that involve doing things
like unlocking a mutex that someone else has locked. You can implement
co-routines in this manner. Besides, if you want a ``safe'' lock, you can
easily build it out of unsafe locks.
> As for conditions, the name is clearly a total loss, since CL already has
> conditions. I also don't know what cthreads conditions are. Perhaps you
> could give a brief description?
Oops. I've changed the name to event. I'll post a summary about how to
use events in a bit. (I want to get this message out before too long.)
ps: My up-to-date interface description is in: