Date: Sun, 20 Sep 1998 19:24:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: info@highwind.com (HighWind Software Information) Cc: rotel@indigo.ie, tlambert@primenet.com, freebsd-current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: HighWind products Message-ID: <199809201924.MAA26989@usr04.primenet.com> In-Reply-To: <199809201256.IAA06956@highwind.com> from "HighWind Software Information" at Sep 20, 98 08:56:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> } Subject: Re: HighWind products > > > } Subject: Re: HighWind products > > > > > > Looks like readdir() is MT safe anyhow. > > > > Only if you use seperate DIR descriptors per thread. > > Yeah, thats a good point, I expect this would be the scenario in > most programs, but I can think of some where it wouldn't. It means > that implementing readdir_r() is as easy as wrapping readdir() with > a lock though. > > We tried that. IT DID NOT WORK. We got all sorts of random memory > corruption with opendir(), lock, readdir(), unlock, closedir(). > > Perhaps the whole sequence needed to be locked? In opendir/readdir/telldir/seekdir/rewinddir/closedir, you need to lock access to the DIR *. You probably need to allocate the dd_loc/dd_buf/dd_len/dd_seek/dd_rewind members of the DIR * in thread local storage. In general, you can't expect to be able to split readdir calls between threads. The way readdir works is to call getdents to fill a user buffer, and then it traverses entries in the user buffer until it gets the last one, after which it calls getdents again. Basically, you have implied lseek context problems. So what is the correct behaviour when calling readdir in several threads on a single descriptor? I don't know... what behaviour are you expecting to have happen? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809201924.MAA26989>