Hi Mathi,
Do you have any comment on the updated patch -
lgsv_missMutexProtection_1705_r3.patch?
Regards, Vu.
>-Original Message-
>From: Lennart Lund [mailto:lennart.l...@ericsson.com]
>Sent: Thursday, April 21, 2016 2:37 PM
>To: Vu Minh Nguyen; mathi.naic...@oracle.com
>Cc:
Hi Vu,
Ack with a minor comment
- The _e suffix for typedef is not used in OpenSAF should be _t e.g.
lgs_state_e -> lgs_state_t
Thanks
Lennart
> -Original Message-
> From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
> Sent: den 20 april 2016 12:16
> To: Lennart Lund;
Hi Vu
I am not surprised that you have found problems in my patch. It was created in
half an hour and not very much tested.
It is mostly an idea of a strategy to handle the problems. I have refined it a
bit hopefully solving the problems you have found so far.
Attached is the refined version.
Hi Vu,
When reviewing this I found several problems. Instead of trying to comment
everything I have instead created a patch of my own.
The main problem fixed by this patch is the handling of the critical section
where both the recovery2 thread and the client thread could handle the same
Hi all,
Friendly reminder for code review.
Regards, Vu.
>-Original Message-
>From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
>Sent: Friday, April 08, 2016 5:04 PM
>To: 'Lennart Lund'; 'mathi.naic...@oracle.com'
>Cc: 'opensaf-devel@lists.sourceforge.net'
>Subject: RE: [PATCH 1
Hi Vu
See my comments inline [Lennart]
Note. My comments does not give the complete solution. For that I need to use
more time but may give you some ideas.
/Lennart
> -Original Message-
> From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
> Sent: den 5 april 2016 10:48
> To:
Hi Lennart,
Thanks for your proposal.
Still, there is race condition b/w mds thread and recover/client thread, I
think.
1) Headless while recover thread 2 is running
2) Headless while the client thread is accessing/modifying to client list.
I would like to propose other one, using only one
Hi Vu,
You are right, good finding, this may happen since the recovery2 thread is
started and is waiting for a timeout. If this timeout happen at the "wrong
time" bad things may happen.
However the actual problem should be solved.
This is how it could be done (maybe you can find a better
Hi Lennart,
Is it possible for following case happens?
Client thread comes to point send_Finalize_msg() @lga_api, then LOG
service up, recovery thread starts and
comes to the point right after "while (pclient != NULL)" in
recovery2_thread @lga_state.c
Then, the context is switching to the
Hi Vu,
/* Recover clients one at a time */
rc = recover_one_client(p_client);
+ if (p_client == NULL) goto done;
+
[Lennart] Why is this needed? This check is done in "while (p_client != NULL)
{ "
and p_client cannot become NULL until "p_client =
Hi Lennart,
Please see my comment inline.
Regards, Vu
Quoting Lennart Lund :
> Hi Vu
>
> Ack with comments
>
> See my comments inline [Lennart]:
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
>> Sent:
Hi Vu
Ack with comments
See my comments inline [Lennart]:
Thanks
Lennart
> -Original Message-
> From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
> Sent: den 23 mars 2016 08:16
> To: mathi.naic...@oracle.com; Lennart Lund
> Cc: opensaf-devel@lists.sourceforge.net
> Subject:
Hi all,
Just friendly reminder for code review.
Regards, Vu.
>-Original Message-
>From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
>Sent: Wednesday, March 23, 2016 2:16 PM
>To: mathi.naic...@oracle.com; lennart.l...@ericsson.com
>Cc: opensaf-devel@lists.sourceforge.net
osaf/libs/agents/saf/lga/lga_state.c | 41 +++
osaf/libs/agents/saf/lga/lga_state.h | 1 +
osaf/libs/agents/saf/lga/lga_util.c | 30 +++--
3 files changed, 50 insertions(+), 22 deletions(-)
There was an race condition between client
14 matches
Mail list logo