On Thu, Oct 8, 2015 at 10:29 AM, Rémi Denis-Courmont <[email protected]> wrote: > Le 2015-10-08 17:21, Hendrik Leppkes a écrit : >> >> pthread is a bit of a exception. All its functions can return errors, >> but the only time they would is if you pass in an invalid argument. > > >> No-one checks return values of pthread_mutex_lock, for example. > > > That is not true. Plenty of projects check for errors there for debugging.
Indeed, see for instance http://www.libsdl.org/tmp/SDL/src/thread/pthread/SDL_sysmutex.c (SDL mutexes) used by avplay. SDL mutex creation and destruction forwards the error to avplay, where it is (currently) not being checked. > >> Only functions worthy of checking are the related init functions. > > > I have to disagree pretty much totally here. > > POSIX thread errors on use (lock, unlock, signal, wait, etc) and destroy > functions should be checked via assertions. I found quite a few bugs in > other projects thanks to that. In debug builds, error detection can be > further improved with the error-checking mutex type instead of the default. > > On the other hand, checking init functions is useless. Any sane POSIX thread > implementation will just initialize memory and always return 0 (glibc does > that, probably musl too). Errors are only specified to allow naive POSIX > implementations to allocate resources; reasonable implementations allocate > all needed resources when creating processes and threads. > > Except for the ETIMEDOUT error, the only really possible failure case is > pthread_create(). > > -- > Rémi Denis-Courmont > http://www.remlab.net/ > > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
