[LTP] [PATCH v1] connectors/cn_pec: improve reliability

Bogdan Lezhepekov bogdan.lezhepekov@suse.com
Fri Aug 6 11:06:32 CEST 2021


Hi Joerg, Petr!

Thanks for reviewing and commenting! I don't have a strong opinion on how the test flow should look like, but I can say this sleep definitely makes the test much more reliable.

The results, we get on known to both of you SUSE Carwos, are pretty consistent. My feeling is that 8/10 runs end up with some sporadic failures. The fact that extra sleep solves the problem obviously indicates a lack of synchronization.

@Joerg: if you need more info about the environment, please reach out to me.

-Bogdan
________________________________
From: Joerg Vehlow <lkml@jv-coder.de>
Sent: Friday, August 6, 2021 11:14
To: Petr Vorel <pvorel@suse.cz>; Bogdan Lezhepekov <bogdan.lezhepekov@suse.com>
Cc: ltp@lists.linux.it <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v1] connectors/cn_pec: improve reliability

Hi Petr,

On 8/6/2021 9:48 AM, Petr Vorel wrote:
>
> If I understand the code correctly, pec_listener keeps receiving msg from PEC
> until got signaled by kill. We generally try to avoid sleep in tests [1].
>
> @Joerg: I'm not sure if it's reasonable to add another signal handler in which
> pec_listener would print number of already handled requests (with write() as
> printf() is not reentrant). Then we could loop for certain time before sending INT.
>
The problem is, that it is hard to know, if all expected events were
received. pec_listener receives events from all processes.
The only way to reliably handle the issue without sleeping is tracking
exit-events in pec_listener and to tell it to die, once it received an
exit event from event_generator.
Only then we can be sure, that all events generated by the generator
(and hopefully all it's children) were received.

We could also get rid of the other sleep (after starting the listener
using some kind of synchronization (I guess right after
PROC_CN_MCAST_LISTEN should work). I think checkpoints are not part of
the new lib...

Joerg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210806/8c6a05fb/attachment-0001.htm>


More information about the ltp mailing list