Hi Hanlin, You mean pthread_cond_wait doesn’t “fix” the mutex after the peer dies? I guess we could try to fix that but what’s the behavior of the app/vpp once that happens? The fact that the mutex is unusable after vcl dies should not matter much as vpp should forcefully cleanup/detach the app once it detects the crash (the socket api should be pretty fast).
Also, how do the apps/vpp end up in this situation? Are they killed or do they crash? Obviously, the latter would be a problem … Regards, Florin > On Dec 7, 2020, at 10:36 PM, wanghanlin <wanghan...@corp.netease.com> wrote: > > Hi Florin, > Same problem for pthread_cond_wait of svm_queue_t, but pthread_cond_wait > seems not robust like pthread_mutex_lock. > > Regards, > Hanlin > > > wanghanlin > > wanghan...@corp.netease.com > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=wanghanlin&uid=wanghanlin%40corp.netease.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22wanghanlin%40corp.netease.com%22%5D&logoUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyeicon%2F209a2912f40f6683af56bb7caff1cb54.png> > 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 > On 12/1/2020 00:10，Florin Coras<fcoras.li...@gmail.com> > <mailto:fcoras.li...@gmail.com> wrote： > Hi Hanlin, > > And here’s the patch [1]. > > Regards, > Florin > > [1] https://gerrit.fd.io/r/c/vpp/+/30185 > <https://gerrit.fd.io/r/c/vpp/+/30185> > >> On Nov 27, 2020, at 9:07 AM, Florin Coras via lists.fd.io >> <http://lists.fd.io/> <fcoras.lists=gmail....@lists.fd.io >> <mailto:fcoras.lists=gmail....@lists.fd.io>> wrote: >> >> Hi Hanlin, >> >> Good point! I actually have that on my todo list to see how/if it affects >> performance. The other way around we should be somewhat safer after the >> switch to the new socket api (instead of the binary api with socket >> transport). That is, vpp detects if an app goes down almost instantly. >> >> Regards, >> Florin >> >>> On Nov 26, 2020, at 11:55 PM, wanghanlin <wanghan...@corp.netease.com >>> <mailto:wanghan...@corp.netease.com>> wrote: >>> >>> Hi Florin， >>> I have another problem about this, that is VPP crash with a mutex lock of >>> svm_queue_t, then VCL hang when locking this mutex, vice versa. >>> Should we use pthread_mutexattr_setrobust_np to solve this problem? >>> >>> Regards, >>> Hanlin >>> >>> >>> wanghanlin >>> >>> wanghan...@corp.netease.com >>> >>> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=wanghanlin&uid=wanghanlin%40corp.netease.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22wanghanlin%40corp.netease.com%22%5D&logoUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyeicon%2F209a2912f40f6683af56bb7caff1cb54.png> >>> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >>> On 3/24/2020 19:56，Dave Barach (dbarach)<dbar...@cisco.com> >>> <mailto:dbar...@cisco.com> wrote： >>> This limitation should come as no surprise, and it’s hardly a “big” >>> limitation. >>> >>> Options include building container images which match the host distro, or >>> using a vpp snap image on the host which corresponds to the container >>> images. >>> >>> Given that there are two ways to deal with the situation, pick your >>> favorite and move on. >>> >>> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io >>> <mailto:vpp-dev@lists.fd.io>> On Behalf Of wanghanlin >>> Sent: Monday, March 23, 2020 10:16 PM >>> To: fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com> >>> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> >>> Subject: Re: [vpp-dev] [VCL] Memory access error for different size of >>> mutex with different glibc versions in VPP and VCL app >>> >>> Hi Florin, >>> It's not only regarding compiled with the same glibc version, but running >>> with the same glibc version also because libpthread is dynamically linked >>> into VCL and VPP. >>> This is really a big limitation. >>> >>> Regards, >>> Hanlin >>> >>> >>> wanghanlin >>> >>> wanghan...@corp.netease.com <mailto:wanghan...@corp.netease.com> >>> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >>> On 3/23/2020 23:31，Florin Coras<fcoras.li...@gmail.com> >>> <mailto:fcoras.li...@gmail.com> wrote： >>> Hi Hanlin, >>> >>> Unfortunately, you’ll have to make sure all code has been compiled with the >>> same glibc version. I’ve heard that glibc changed in ubuntu 20.04 but I >>> haven’t done any testing with it yet. >>> >>> Note that the binary api also makes use of svm_queue_t. >>> >>> Regards, >>> Florin >>> >>> >>> On Mar 22, 2020, at 10:49 PM, wanghanlin <wanghan...@corp.netease.com >>> <mailto:wanghan...@corp.netease.com>> wrote: >>> >>> Hi All, >>> Now, VCL app and VPP shared some data structures, such as svm_queue_t. In >>> svm_queue_t, there are mutex and condvar variables that depends on >>> specified glibc version. >>> When VPP run in host and VCL app run in a docker container, glibc versions >>> maybe different between VPP and VCL app, and then result in memory access >>> error for different size of mutex and condvar. >>> Has anyone noticed this? >>> >>> Regards, >>> Hanlin >>> >>> wanghanlin >>> >>> wanghan...@corp.netease.com <mailto:wanghan...@corp.netease.com> >>> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >>> >> >> >> >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18281): https://lists.fd.io/g/vpp-dev/message/18281 Mute This Topic: https://lists.fd.io/mt/72485607/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
