[LTP] [PATCH RFC] fzsync: tst_fzsync_pair_wait exit when parent hit accidental break

[Li Wang]

Hi Richard,

Richard Palethorpe <rpalethorpe@suse.de> wrote:

> > Well we can have a try, seems the only disadvantage of this method is
> > thread_B sets signal handler at each loop start in tst_fzsync_run_b
> > repeatedly.
>
> We could wrap thread B's main function 'run_b', which is passed to
> tst_fzsync_pair_reset, in another function which sets the singal handler
> at the start of the thread.

Good suggestion! This make sense to me.

> > -       /** Internal; Used by tst_fzsync_pair_exit() and fzsync_pair_wait() */
> > -       int exit;
>
> I was thinking of keeping the exit variable and using the kill signal as
> a backup. The reason being it should allow thread B to exit gracefully
> in most scenarious. In theory this should not matter because the test
> writer should not do any setup in thread B, but it might result in some
> wierd error/warning messages being printed for some tests.

Yes, that's not a bad solution, but I was a little worried before is
that would make things a bit mixed for the thread exiting. However, if
we use pair->exit only for normal exiting and signal for unexpected
abort, that's also accessible I guess.

>
> Unfortunately pthread_join has no timeout and pthread_timedjoin_np is
> non-standard.

or maybe we could achieve a LTP private pthread_timedjoin_np version? I haven't
look into more about that so have no idea for the detail/complexity.

>
> Another option might be to spin-wait for 'exit' to be incremented to 2
> by thread B and send the signal after some arbitrarily large number of
> spins. What do you think?

Hmm, what's the best value for arbitrarily large number? it seems hard
to decide.

Comparing the above approaches, currently it's hard to say which one
is better. If I have to make a choice, I'd like to try the first
method: pair->exit (for normal exiting) + signal(for unexpected
abort).

-- 
Regards,
Li Wang