Possible language changes

[Douglas C. Schmidt]

Hi Doug,

>  > class Thread
> 
> >    thread_t spawn (void * (*func) (void *),
> >                    void *arg = 0,
> >                    Thread_Params *thread_parameters = 0);
> 
> 1. Is there a good reason for separating thread_t and Thread?
>     It would be nicer to say "Thread* t = new Thread(...)
>     rather than thread_t t = Thread::spawn(...).

Sure, though for this sort of capability I'd recommend going with the
more sophisticated "OO" approach I mentioned first, i.e., something more
like Java's Thread and ACE_Task.

> 2. How burdensome would it be to require a little closure object
>     instead of function pointer? Something like Java Runnable,
>     although it would be better to use something like (j2SE5)
>     Callable that can take arg, return result, and report exception.

Yes, that's also quite doable, as well.  I was just sticking to "bare
bones" to get the approach across quickly ;-)

> 3. Are there any spec tricks that would allow Thread_Params to
>     be partially implementation defined? Like to have a
>     required basic base class, and then an optional
>      PThread_Params sublass etc?

Yes, indeed.  Something like that might also a nice solution to some
other portability issues I alluded to wrt methods like signal(),
cancel(), etc.  For example, there could be a subclass called
POSIX_Thread that adds these additional capabilities.  Clearly, this
could get out of control, so it might make sense to 

. Only define subclasses for well defined standards (e.g., POSIX).

. Make the framework extensible so that vendors could extend it to 
  work on other non-standard systems.

> >                /**
> >    * Wait for a thread specified by @a thread_id to exit and
> >    * optionally returns its @a exit_status.  Does not wait on detached
> >    * threads.    * Can throw various exceptions on failure (TBD).
> >    */
> >   void wait (thread_t thread_id, void *exit_status = 0);
> 
> (Note that exit status part probably goes away if you use something like
> Callable)

Right - I'm definitely not advocating we go with the "bare bones"
approach.  I like the OO style better (but that's just me).

> >   /**
> >    * Cancel a single thread.  Not supported on platforms
> >    * that do not have advanced cancellation support.
> >    * Can throw various exceptions on failure (TBD).
> >    */
> >   void cancel (thread_t, bool async_cancel = false);
> 
> Just right! (the "async_cancel" is basically the same as
> we did for Futures in java.util.concurrent.)

BTW, async_cancel is something that could be provided via a subclass
like POSIX_Thread since it isn't viable in general.

> >   /// I've intentionally omitted all suspend()/resume() methods
> >   /// since they are badly flawed, non-portable, and can't be used
> >   /// properly.
> 
> We (for j.u.c) ended up liking "park/unpark" for this. It is defined
> in a very portable way, and is VERY handy for building other things
> with, but not very useful by itself, which is just perfect here.
> See
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/locks/LockSupport.html

Cool!  

> Is a Thread_group joined automatically when constructing thread?
> Similarly for remove?

I see various ways to do this:

. Merge Thread_Group functionality with the core Thread abstraction,
  which would address your question above (and is also how we do
  it in ACE).
  
. Keep the two classes separate but make it possible to associate
  a Thread_Group with a Thread.  I think this is how Java does it,
  right?

Thanks,

        Doug