Re: [Dar-libdar_api] Re: problem compiling KDar with libdar CVS
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
|
From: Johnathan B. <jk...@us...> - 2004-11-06 22:53:51
|
Hi Denis, On Wednesday 03 November 2004 13:08, Denis Corbin wrote: > Denis Corbin wrote: > |[...] > | 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. > | > | > |[...] > > Hello, > > This is implemented and tested. CVS is up to date. If you have no > objections, The API is now frozen (version 3) for the release 2.2.0 that > will come in december I hope. The points that remains to do before the > pre-release phase are : > - documentation (API, user guide, etc.) > - password/key from file > - password/key from keyboard out of command-line > - some few other strong encryption algorithms > - LZO compression > > the two password/key features do not have any impact on the API (these > are command-line related feature). The LZO and the new cypher support > only add some more values in the "enum compression" and "enum > crypto_algo" enumeration types. > > The pre-release target date is the beginning of december. Until that > time, it is still time to fix API problem you could meet, so please give > your feedback before pre-release phase. I've got KDar running on libdar API V3.0.0, CVS. Works great! The thread cancelation works perfectly, my limited testing shows. The response is very snappy, and the user does not have to wait or restart= =20 the program to stop an operation anymore. I think that you have a good=20 implementation of thread cancelation. Quite elegant. One point about libdar's "make install": the config.h header that gets put= =20 into <installdir>/include/dar/ does not contain "#define MUTEX_WORKS 1"=20 when I configure libdar with pthreads, so I have to add it manually to get= =20 KDar to compile. As an aside, here is a tip for people who want to implement thread=20 cancellation in QT: Note that to cancel a libdar operation, you need to pass the ID of the=20 thread to cancel to libdar::cancel_thread(). You have to get this ID from=20 the "run()" method of the QThread, not it's constructor or anywhere else.=20 i.e. put "pthread_self()" inside run() and store it with a protected=20 member variable. This is not well documented by Trolltech, and it had me=20 puzzled for many hours today... [...] Cheers, JB =2D-=20 Johnathan K. Burchill, Ph.D. jk...@us... |