|
From: Johnathan B. <jk...@sh...> - 2004-06-28 21:10:57
|
On June 28, 2004 01:29 pm, Denis Corbin wrote:
> Johnathan Burchill wrote:
> > On June 19, 2004 02:43 pm, Denis Corbin wrote:
> >>Johnathan Burchill wrote:
> >>>On June 19, 2004 09:59 am, Johnathan Burchill wrote:
> >
> >[...]
> >
> >>>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?
>
> no signal handlers are not based on polling: you associate a function
> (=3Dhandler) to a signal thanks to the signal() system call and when a
> process receive the given signal (either from the system or from another
> process thanks to the kill() system call) the given handler is run, and
> once finished the execution of the process continues transparently,
> unless the handler stops the process (thanks to the exit() standard call
> and so on).
>
> > What are the problems with polling? I am not familiar with the issues.
> > Portability? CPU cycles? ...?
>
> I don't like it because it makes algorithm more complex and less
> performant due to CPU cycle wasted checking someting has not changed
> most of the time.
>
> > 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
> > }
> > }
>
> I seems we must forget the signal mechanism, as described here :
> http://www.burningvoid.com/iaq/posix-signals.html
> "One important safety tip is that pthreads constructs like mutexes,"
> "condition variables, etc. do not have defined behavior inside signal"
> "handlers. So you cannot use pthreads calls or synchronize with other"
> "threads while inside a signal handler."
>
> > 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 =3D 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.
>
> I would prefer another direction. (reference:
> http://www.llnl.gov/computing/tutorials/workshops/workshop/pthreads/MAIN
>.html )
> Based on the information found in the previous web site, I would
> prefer the following mechanism:
>
> before entering a critical section (bounded by a mutex) in libdar, set
> the cancel state to DISABLE thanks to the pthread_setcancelstate() call.
>
> after exiting a critical section (still in libdar) set the cancel state
> back to ENABLE.
>
> If a multi threaded program wants to cancel a thead while calling a
> libdar routine, it would just need to call the pthread_cancel() routine
> on the corresponding thread.
>
> If the libdar code is out of a critical section the thread exits
> immediatly, if it is inside a critical section the thread exits once
> cancel state is enabled back after the critical section.
=46rom the man page for pthread_cancel(), it seems that with the cancel=20
state set to DISABLE, the thread will ignore the cancel call, not defer=20
it. So it would be hit-and-miss with a user trying to cancle the thread,=20
depending on whether the thread is in some critical part or not.
To defer the cancel call, you set the cancel type to defer. Then your code=
=20
tests for the cancel signal at various points in the non-critical parts,=20
the so-called "cancel points".
Do I interpret that man page correctly?
>
> This way the global mutex objects stay in coherent state and thus it is
> possible to safely cancel a thread calling libdar routine.
>
> By the way, note that the mutex used by libdar (and common to all
> threads) are never released. If this is a problem it might be possible
> to add a call in the API to release them and in consequence forbid any
> further call to libdar. The mutex used do not take much memory place
> however.
>
In other words, the mutexes are created on the stack?
> >[...]
> >
> > JB
>
> What's your objections if any ? ;-)
Just so I understand this, would I call pthread_create, with the name
of the libdar operation function as an argument? Or have you implemented=20
the libdar operations now as threads?
>
> I have at least one for now : it does not handle the allocated memory
> from the thread by libdar.
According to the pthread_cancel manpage,=20
When a thread eventually honors a cancellation request, it
performs as if pthread_exit(PTHREAD_CANCELED) has been
called at that point: all cleanup handlers are executed in
reverse order, finalization functions for thread-specific
data are called, and finally the thread stops executing
with the return value PTHREAD_CANCELED. See
pthread_exit(3) for more information.
Could the cleanup handlers handle the allocated memory?
>
> Cheers,
> Denis.
>
Cheers,
JB
=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...
|
