Open ycaibb opened 2 years ago
Hello yccaib, Thanks for writing in. If you are concerned about pthread_mutex return values not being checked, this is probably not the web server for you. I'm guessing there are more egregious correctness issues.
However, I would take a pull request that handles the mutex locking failures. Besides EAGAIN, I'm guessing you would want to:
Although really I'm guessing we would just want an ews_printf() in that case, and no users would ever set OptionCrashOnMutexLockFailure to true.
I'm not really sure there's an option to gracefully recover from the pthread_mutex lock failure. And it should be extremely rare.
I will say that the only time I have ever seen pthread_mutex functions return non-zero are when I forget to initialize them.
Although I would rather someone add support for handling the HTTP Range: header. That would be preferred and cool.
Hi, developers, I have a suggestion about error handlings for locking. Would it be better to handle the possible errors that return from pthread_mutex_lock.
Possible situations that return errors.
https://github.com/hellerf/EmbeddableWebServer/blob/9d71cee513e2eae98d1676b554385c7e894096db/EmbeddableWebServer.h#L1920-L1922
For example, this example does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program (CWE-413). The manners of error handlings could be flagging any warnings or returning before accessing the critical region.