Re: Re: [Dar-discussions] Re: Fwd: I would like to cancel archive creation

On June 28, 2004 01:29 pm, Denis Corbin wrote:
> 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.

From the man page for pthread_cancel(), it seems that with the  cancel 
state set to DISABLE, the thread will ignore the cancel call, not defer 
it. So it would be hit-and-miss with a user trying to cancle the thread, 
depending on whether the thread is in some critical part or not.

To defer the cancel call, you set the cancel type to defer. Then your code 
tests for the cancel signal at various points in the non-critical parts, 
the so-called "cancel points".

Do I interpret that man page correctly?

>
> 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.
>

In other words, the mutexes are created on the stack?

>  >[...]
> >
> > JB
>
> What's your objections if any ? ;-)

Just so I understand this, would I call pthread_create, with the name
of the libdar operation function as an argument? Or have you implemented 
the libdar operations now as threads?

>
> I have at least one for now : it does not handle the allocated memory
> from the thread by libdar.

According to the pthread_cancel manpage, 

       When a thread eventually honors a cancellation request, it
       performs as  if  pthread_exit(PTHREAD_CANCELED)  has  been
       called at that point: all cleanup handlers are executed in
       reverse order, finalization functions for  thread-specific
       data  are  called,  and finally the thread stops executing
       with   the    return    value    PTHREAD_CANCELED.     See
       pthread_exit(3) for more information.

Could the cleanup handlers handle the allocated memory?

>
> Cheers,
> Denis.
>

Cheers,
JB
-- 
Johnathan K. Burchill, Ph.D.
Department of Physics and Astronomy
University of Calgary
2500 University Drive N.W.
Calgary, AB T2N 1N4
Canada

(403) 217-4286
[email protected]


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com