From: "Ted Unangst" Subject: Re: pthread_rwlock_combo To: "Ingo Schwarze" Cc: tech@openbsd.org Date: Sat, 05 Jul 2025 12:26:22 -0400 On 2025-07-04, Ingo Schwarze wrote: > Hello Ted, > OK schwarze@. thanks. > I realize you did not add the following sentence: > > The results of acquiring a read lock while the calling thread > holds a write lock are undefined. > > That sentence is already in pthread_rwlock_rdlock(3), but it > contradicts our own manual page, which says: I deleted that. > Looking at our code, my impression is that this EDEADLK behaviour > is described correctly and we conform to POSIX in this respect, > so i think you should simply delete the two lies about undefined We have other lies, however. pthread_rwlock_unlock never returns any errors. I have left this for now. I think the entire library needs a fact check. > Below HISTORY, the "first appeared in FreeBSD 3.0" might be a lie - > or are the functions really FreeBSD inventions? Also, you lost part > of the OpenBSD history. I'd suggest dropping the FreeBSD history > and simply saying: I dropped the section. Very few of the other pages seem to have it. I don't think it's very useful? We can add it back, but I'd prefer to consistent. We have some text in pthreads.3 about the library, maybe that can be expanded. > The STANDARDS section should probably be updated, -susv2 sounds > unusually old-fashioned, but no need to mix that into this diff. Yeah, that needs checking and consistency. I don't really like the "expected to conform" language. We don't know? But I also don't like "conforms to" language. Did we check? We have this language everywhere, but maybe we can consider it again. What about saying "These functions are specified by .."?