> On March 17, 2017, 2:38 a.m., Andrew Stitcher wrote:
> > This looks good: Note there is also a PN_WEAKREF object type which might 
> > also solve the problem, but I'm not entirely sure.

See the new diff - made it a proper pn_class of its own with `_finalize` to 
call mutex_destroy. I don't eve want to guess what PN_WEAKREF means in the 
world of proton refcounting.


- Alan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57702/#review169250
-----------------------------------------------------------


On March 19, 2017, 4:54 p.m., Alan Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57702/
> -----------------------------------------------------------
> 
> (Updated March 19, 2017, 4:54 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> -------
> 
> PROTON-1440: libuv proactor - thread safe pn_connection_wake
> 
> This fix does not change the API but makes pn_connection_wake thread safe.
> 
> To be thread safe we need to a lock, so the pconnection_t attachment stays
> on the pn_connection_t until the pn_connection_t is destroyed.
> 
> pn_proactor_free also was modified to run the normal socket close sequence
> rather than a short-cut that just closes TCP sockets - this allows the
> wake locking logic to run as normal, even if the application calls wake
> after the proactor is freed.
> 
> also at https://github.com/alanconway/qpid-proton/tree/safe-wake
> 
> 
> Diffs
> -----
> 
>   proton-c/bindings/cpp/src/contexts.cpp 
> 8da8f7cf5b64c75e7eaddc27069b8a7160e6f9d6 
>   proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d 
>   proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 
> 
> 
> Diff: https://reviews.apache.org/r/57702/diff/2/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Reply via email to