[Dar-libdar_api] Re: problem compiling KDar with libdar CVS

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| On Monday 01 November 2004 11:48, Denis Corbin wrote:
|
|>Denis Corbin wrote:
|>| Hello Johnathan,
|>|
|>|[...]
|>|
|>| Things to review in the API are :
|>| - op_create & other functions must become methods of the archive class
|>| (for a more correct C++ design)
|>
|>this has been done today (CVS). Still needs documentation.
|>
|>| - what about thread cancelation ? Do we assume kdar will fork() rather
|>| than require a more complex mechanism to cancel a thread ?
|
|
| One weekend a while back I attempted to get the fork() working, with no
| success. There was some problem with forking a qt application and I did
| not understand how to fix it. I'd much prefer to stick with the thread
| cancellation technique.
|

OK

|
|>If the thread cancelation does not implies any change, then we are very
|
|
| It depends how you implement it. You once suggested a wrapper class that
| polls for a signal and throws an Euser_abort() if there is a cancellation
| request. What signal would it look for? Would it be independent of any of
| the pthread functions? How would the application set the signal?

the implementation I am working on does not rely on Unix signaling.

|
| Another way is to use cancellation points suitably located througout the
| code (see "man pthread_cancel"). As far as I can tell, what is needed is
| #include <pthread.h> and a bunch of pthread_testcancel()'s.
| You need so-called cancellation cleanup handlers for unlocking mutexes
and
| freeing memory (see "man pthread_cleanup_push" and the examples therein).
|
| It may require quite a bit of work. Also, I don't know whether it is
| directly portable to the cygwin version of libdar.

where there will not be pthread mutex available there will not be thread
cancelation available (and probably the system will not support
multi-threading neither). All is activated from the configuration script.

|
|
|>near the definitive API specifications for version 3 so we could
|>"freeze" the API. Some last feature will only add a type in enumeration
|>(LZO compression, RSA encryption, etc.), but class, function or methods
|>definitions should not change at all.
|
|
| Making the threads cancellable should not affect the API in any
significant
| way. Since the various libdar operations are now archive methods, you
| should have an "archive::cancel_operation()" method that toggles a
boolean
| which triggers the "Euser_abort()" exception between the filesystem reads
| or writes.

This is not possible this way, I proposes the following API :

~    void cancel_thread(pthread_t tid);
~    bool cancel_current(pthread_t & tid);
~    void cancel_clear();

where cancel_thread() is used to cancel the given thread. Which will
make libdar throw a Euser_abort exception, cleanly free memory and
release any mutex.

cancel_current() return true and the tid of the thread that will be
canceled when execution will reach the next checkpoint, false if there
is not pending cancelation.

cancel_clear() abort cancelation process if the thread has not already
terminated.

Only one thread can be canceled at a time.


|
| Now that I'm beginning to understand your wrapper class idea, I rather
like
| it.

;-)

The mechanisme is the following. When cancel_thread is called, it put
the requested tid in memory of a thread_cancelation object. Some key
classes (sar, tuyau, fichier and null_file) now inherit from the
thread_cancelation class. Thus they dispose of a method to check if the
thread Id (tid) they are run from has not been designed for cancelation.
If so the method throws the Euser_abort execption, which has the final
consequence of cleanly returning from the current libdar call.

the sar, tuyau fichier and null_file are the one used as low layer
objects in archive operation. The thread_cancelation checkpoint is put
in their read and write functions. To not overload the checkpoint
process I have limited the implementation to have a simple check. The
drawback is that only one thread can be canceled at a time (need to wait
for the cancelation has complete to as for a new cancelation).

Implementation is finished, I am testing it, and should upgrade CVS
tomorrow if all is fine.

|
| Cheers,
| JB
|

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBiBDWpC5CI8gYGlIRAsCVAJ44wNiSKbn6rq4f5btWK0oLvW0JCACggSTi
m1PO5FMg5IlbLC9T4jjNPNE=
=lukb
-----END PGP SIGNATURE-----