Used wrong from address... :( On Mon, 10 Feb 2025, Jeremy Drake wrote:
> On Mon, 10 Feb 2025, Corinna Vinschen wrote: > > > Yes, dos_drive_mappings() is what I really meant, thanks for pointing > > it out. > > > > So I wonder why not include your additional requirements into the > > dos_drive_mappings class and just use it to iterate over the mount > > points. AFAICS there are only two things missing in dos_drive_mappings: > > > > - looking for all mount points, not just the first one, and > > - bookkeeping over getmntent calls > > > > If you add a state pointer (pointing to the current mapping) to > > dos_drive_mappings, you only need a single slot in the TLS, holding a > > pointer to your dos_drive_mappings instance. > > This would be much cleaner, I think. I'll look at this. > > > [...time passes...] > > > > Hang on, there might be a bug here... > > > > [...time passes...] > > > > Why do we keep the cygdrive state in cygtls anyway? From history I see > > that this has been the case since at least 2003. > > > > Per definition, getmntent isn't thread-safe at all, and getmntent_r is > > only thread-safe in that it keeps the data in a buffer provided by the > > caller. > > However, the state information is process-wide: if you call getmntent > > alternating in two different threads, they don't see the same set of > > drives, but only every second drive. > > > > At least this is the case on Linux. Don't we subvert expectations > > by handling getmentent thread-local? > > > > If I'm thinking to much outside the box, feel free to kick me. > > That's well outside my scope ;). I think 1) getmentent is pretty well > deprecated, and 2) if something isn't defined to be thread-safe, pretty > much anything it happens to do in the face of multiple threads using it is > fine (to me, we're in the realms of UB here). >
