Re: Re: problem compiling KDar with libdar CVS

Johnathan Burchill <[email protected]> Mon, 01 Nov 2004 17:54:29 -0700
Newsgroups gmane.comp.sysutils.backup.dar.libdar
Organization Department of Physics and Astronomy, University of Calgary
Message-ID <[email protected]>
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.

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

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.

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

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

Cheers,
JB

>
> My current actions are the following in order of priority:
> - documentation (review all in HTML format, API documentation first)
> - finish strong encryption (password from interactive question, or from
> file, some few other strong encryptions algorithms)
> - LZO compression if time allows it (all development stop at end of
> November for 2.2.0 pre-release phase)
>
> | Cheers,
> | Denis.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Dar-libdar_api mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

-- 
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]
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBhtrLrXMSOtiWrO4RAvYoAJsG1Z5PeRuU4EaVqlyb+y2kFM1gXQCgjk0e
N6cEBXBeAAqd5tLm9+9/ruY=
=qziB
-----END PGP SIGNATURE-----