Custom Query (204 matches)

Hi/2.

pthread_rwlock_trywrlock() should return EBUSY when the other thread already had a rdlock or a wrlock.

Hi/2.

Let's see the following case.

1. main thread: acquire rdlock
2. second thread: try to acquire wrlock
3. third thread: try to acquire tryrdlock

In 2., CPU load gets to 99.9% because of a tight loop in pthread_rwlock_wrlock(). And In 3., deadlock occurs in pthread_rwlock_tryrdlock() because lock->mutex is not released in pthread_rwlock_wrlock().

This occured in the test of pthread_rwlock_rdlock.m4.

I ran into a problem with the p7zip command 7za w:\temp\M.7z M:\ (mentioned in ​https://www.os2world.com/forum/index.php?topic=1941.0) attempting to archive an entire volume and reported it to Ruediger Ihle and he responed:

I did some more testing and it turns out the klibc is the culprit! The problem is, that when the functions opendir()/readdir() are asked to retrieve the content of a root directory (i.e. "X:/*"), they erroneously return the content of the *current* directory on that drive.

Note: I gave this a low priority because I've been able to bypass my problems with zip, and it runs faster than p7zip. However, I can't guaranty that it's not important to other customers running into the same problem in a different application.