|
From: Denis C. <dar...@fr...> - 2004-06-28 19:26:59
|
Johnathan Burchill wrote:
> On June 19, 2004 02:43 pm, Denis Corbin wrote:
>
>>Johnathan Burchill wrote:
>>
>>>On June 19, 2004 09:59 am, Johnathan Burchill wrote:
>>>
>[...]
>>
>>>Any comments?
>>
>>What standard mechanism over signal handlers can preempt a thread and
>>let it do some arbitrary action ? I don't like polling. :-/
>>
>
>
> Signal handlers are based on polling, right? When you say polling, do you
> mean that within your libdar operation loop a conditional statement checks
> to see if a signal has been set?
no signal handlers are not based on polling: you associate a function
(=handler) to a signal thanks to the signal() system call and when a
process receive the given signal (either from the system or from another
process thanks to the kill() system call) the given handler is run, and
once finished the execution of the process continues transparently,
unless the handler stops the process (thanks to the exit() standard call
and so on).
>
> What are the problems with polling? I am not familiar with the issues.
> Portability? CPU cycles? ...?
I don't like it because it makes algorithm more complex and less
performant due to CPU cycle wasted checking someting has not changed
most of the time.
>
> I would suggest a public variable that can be set by the calling thread,
>
> bool stop( false );
>
> and in the definition,
>
> while (...) //libdar::operation loop
> {
> if ( !stop )
> {
> ...libdar operations...
> }
> else
> {
> ...clean up premature stop...
> ...break out of operation loop
> }
> }
>
I seems we must forget the signal mechanism, as described here :
http://www.burningvoid.com/iaq/posix-signals.html
"One important safety tip is that pthreads constructs like mutexes,"
"condition variables, etc. do not have defined behavior inside signal"
"handlers. So you cannot use pthreads calls or synchronize with other"
"threads while inside a signal handler."
> Although this might present a problem when, say, you are testing two
> separate archives at the same time, but you decide to cancel just one of
> them. Instead, you could add an additional argument to the libdar call:
>
> libdar::statistics st = libdar::op_test( theArchive, ... other
> arguments ..., (bool *) stop );
>
> The (bool *) points to a protected or private member variable of the
> calling thread, so we could cancel one operation, keeping others going.
I would prefer another direction. (reference:
http://www.llnl.gov/computing/tutorials/workshops/workshop/pthreads/MAIN.html
)
Based on the information found in the previous web site, I would
prefer the following mechanism:
before entering a critical section (bounded by a mutex) in libdar, set
the cancel state to DISABLE thanks to the pthread_setcancelstate() call.
after exiting a critical section (still in libdar) set the cancel state
back to ENABLE.
If a multi threaded program wants to cancel a thead while calling a
libdar routine, it would just need to call the pthread_cancel() routine
on the corresponding thread.
If the libdar code is out of a critical section the thread exits
immediatly, if it is inside a critical section the thread exits once
cancel state is enabled back after the critical section.
This way the global mutex objects stay in coherent state and thus it is
possible to safely cancel a thread calling libdar routine.
By the way, note that the mutex used by libdar (and common to all
threads) are never released. If this is a problem it might be possible
to add a call in the API to release them and in consequence forbid any
further call to libdar. The mutex used do not take much memory place
however.
>[...]
>
> JB
What's your objections if any ? ;-)
I have at least one for now : it does not handle the allocated memory
from the thread by libdar.
Cheers,
Denis.
|
