Re: [Merge] ~epics-core/epics-base/+git/Com:thread-join into epics-base:7.0

[mdavidsaver via Core-talk <core-talk@aps.anl.gov>]

> But there is a cure: https://plugins.jenkins.io/build-timeout

I agree an overall timeout would be a better way to solve the Bothering Andrew part of this problem.

If Jenkins can't be made to work, then maybe makeTestfile.pl could be taught about SIGALRM.

> If it's too hard to implement a timeout on Posix I would accept that as a reason for not adding it

The standard pthread_join() doesn't have a timeout.  A quick search finds pthread_tryjoin_np(), which is a glibc extension.

> that epicsThreadJoin() should return a status

What status?  How would a caller react?

Part of my reasoning for not having a return value is that by the time a join is performed, there often isn't anything sensible to be done.

eg. I regard epicsMutexLock() returning as a mis-feature.  There is nothing sensible which user code can do with a epicsMutexLockError.  So why offer up the option?  Seems an invitation to ignore a serious error.

-- 
https://code.launchpad.net/~epics-core/epics-base/+git/Com/+merge/361379
Your team EPICS Core Developers is subscribed to branch epics-base:7.0.