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

[Johnathan B. <jk...@sh...>]

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=20
success. There was some problem with forking a qt application and I did=20
not understand how to fix it. I'd much prefer to stick with the thread=20
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=20
polls for a signal and throws an Euser_abort() if there is a cancellation=20
request. What signal would it look for? Would it be independent of any of=20
the pthread functions? How would the application set the signal?

Another way is to use cancellation points suitably located througout the=20
code (see "man pthread_cancel"). As far as I can tell, what is needed is=20
#include <pthread.h> and a bunch of pthread_testcancel()'s.
You need so-called cancellation cleanup handlers for unlocking mutexes and=
=20
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=20
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=
=20
way. Since the various libdar operations are now archive methods, you=20
should have an "archive::cancel_operation()" method that toggles a boolean=
=20
which triggers the "Euser_abort()" exception between the filesystem reads=20
or writes.

Now that I'm beginning to understand your wrapper class idea, I rather like=
=20
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=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

=2D-=20
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
jk...@sh...