[cpp-threads] pthreads cancellation

[Andrei Alexandrescu]

I, too, think that we shouldn't hard real-time issues.

Also, speaking of thread cancellation, I propose (and I know this is a 
hard-to-swallow proposal) that we don't include any API that forcefully 
terminates a thread without that thread's cooperation. Threads are easy 
to start but essentially unstoppable unless they're willing to.

Ideally, we'd include some library primitives that foster 
easy-to-implement thread termination in a cooperative manner, a la:

void ThreadFunc(args) {
     while (!threads::shutting_down()) {
         ... do useful stuff ...
     }
}

void MainWindow::OnWindowClose(args) {
     ...
     threads::shutdown(threads::all);
     ...
}

That also reminds me of something else. We need to define what the 
threading behavior for various standard lib functions is, particularly 
potentially blocking functions such as I/O. That is essential to writing 
proper shutdown code.

For example, we should specify that any file close operation in one 
thread is causing immediate (time-bounded) termination of any I/O 
operations on that file in any other thread, with an error. If sockets 
will be also added to the standard library, we'd need to similarly 
specify that closing a socket in a thread cancels with an error any 
blocking operation on that socket.

This is what actually happens, but we need to ratify it in the standard; 
otherwise, thread termination and clean application shutdown are not 
feasible portably.


Andrei

Boehm, Hans wrote:
> This brings up an excellent point:
> 
> Are we trying to address (hard) real-time issues with the threads API?
> 
> My personal feeling is that real-time programming is really a
> completely different beast, and that pthreads has suffered a bit
> by trying to do two things at once.
> 
> In my view, RTSJ != Java.
> 
> As far as C++ is concerned, I think in the discussion you referenced,
> Fergus Henderson makes exactly the point I was trying to make.
> 
> Hans 
> 
> 
>>-----Original Message-----
>>From: 
>>Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
>>[mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
>>.org.uk] On Behalf Of Alexander Terekhov
>>Sent: Wednesday, April 27, 2005 5:04 AM
>>To: cpp-threads at decadentplace.org.uk
>>Subject: Re: [cpp-threads] pthreads cancellation
>>
>>
>>On 4/26/05, Boehm, Hans <hans.boehm at hp.com> wrote:
>>[...]
>>
>>>Java got rid of anything resembling asynchronous cancellation
>>
>>Really?
>>
>>http://www.rtj.org/rtsj-V1.0.pdf
>>
>>"The interrupt() method in java.lang.Thread provides rudimentary 
>> asynchronous communication by setting a pollable/resettable flag 
>> in the target  thread, and by throwing a synchronous exception  
>> when the target thread is blocked at an invocation of wait(), 
>> sleep(), or join(). This specification extends the effect of 
>> Thread.interrupt() and adds an overloaded version in 
>> RealtimeThread, offering a more comprehensive and non-polling 
>> asynchronous execution control facility. It is based on throwing 
>> and propagating exceptions that, though asynchronous, are 
>> deferred where necessary in order to avoid data structure 
>> corruption.
>>
>> [...]
>>
>> When a method is declared with AsynchronouslyInterruptedException 
>> in its throws clause the platform is expected to asynchronously 
>> throw this exception if RealtimeThread.interrupt() is called while 
>> the method is executing, or if such an interrupt is pending any 
>> time control returns to the method. The interrupt is not thrown 
>> while any methods it invokes are executing, unless they are, in 
>> turn, declared to throw the exception. This is intended to allow 
>> long-running computations to be terminated without the overhead 
>> or latency of polling with java.lang.Thread.interrupted()"
>>
>>Please visit also
>>
>>http://www.codesourcery.com/archives/c++-pthreads/msg00124.html
>>http://www.codesourcery.com/archives/c++-pthreads/msg00144.html
>>
>>regards,
>>alexander.
>>
>>-- 
>>cpp-threads mailing list
>>cpp-threads at decadentplace.org.uk 
>>http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
> 
> entplace.org.uk
>