Print

Print


Well, interestingly some of the traces above do not show garbage. If garbage is shown in others then clearly this is likely a race condition. If garbage is shown then the mutex has been freed but the other party thinks it is still valid so the result is undefined (i.e. weird things happens). I've always been against an external "tick" master as they usually create more problems than they solve simply because they create race conditions. I know a lot of work has gone into not depending on them and using the event timeouts as the primary source of events timeouts which avoids race conditions. It seems we still have some things controlled by an external evil witch (i.e. a timeout handler). Architecturally that will always pose problems. So, maybe this is a good time to see if we can eliminate the last dependency on this kind of parallel nonsense.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1883/1439620030@github.com>

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1439620030", "url": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1439620030", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1