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

On June 19, 2004 02:43 pm, Denis Corbin wrote:
> Johnathan Burchill wrote:
> > On June 19, 2004 09:59 am, Johnathan Burchill wrote:
> >>Hi Denis,
>
> Hello Johnathan,
>
> >>I received this from a kdar user who asks whether it is possible to
> >>cancel a libdar operation. My first attempt will be to add the
> >> "dry-run" feature to the creation process. However, this is not a
> >> "quick" test of the backup, I think it takes a time comparable to the
> >> actual backup. Is this right?
>
> I think this is faster, but I have not made real comparison ;-)
>
> >>As far as interrupting the creation process, now that libdar is
> >>thread-safe, would there be a way to send it a "kill" signal, to get
> >> it to stop what it is doing? A couple of people have asked for this
> >> feature.
>
> does a SIGTERM handler would help ? There is a mutex to release, file
> descriptors to close, and memory to release. I suspect Linux closes file
> descriptors let openned by the thread, but it cannot obviously be done
> the same for mutex (which are shared by all threads). For other system I
> don't know what's the behavior about file descriptors.
>
> > QT has a method for terminating a thread, but this warning comes with
> > the documentation:
> >
> > Warning: This function is dangerous, and its use is discouraged. The
> > thread can be terminate at any point in its code path. Threads can be
> > terminated while modifying data. There is no chance for the thread to
> > cleanup after itself, unlock any held mutexes, etc. In short, use this
> > function only if absolutely necessary. (from
> > http://doc.trolltech.com/3.3/qthread.html)
> >
> > For the command line dar, a <Ctrl>-C will interrupt the libdar
> > operation. I'm guessing that the terminate method is the equivalent
> > for the QT GUI version. In dar-2.1.3, the library is not thread safe,
> > so I only run one operation at a time, and killing the operation
> > shouldn't be problematic as there are no locked mutexes. This should
> > be like hitting <Ctrl>-C. But the new threadsafe library may have
> > issues with this technique.
>
> yes.
>
> > 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?

What are the problems with polling? I am not familiar with the issues. 
Portability? CPU cycles? ...?

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

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.

A problem with this technique is that it is inflexible. I'm not sure that 
this is really significant though. Why would it be necessary for libdar to 
be able to handle arbitrary signals?

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]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQBA34gYrXMSOtiWrO4RAviIAKDPM1ZJdm0LHk27llsRUnTnCr7RhgCgiFiA
hlfn2Pu31qVJLEJMCLPUCjs=
=eZG/
-----END PGP SIGNATURE-----