non-blocking Unix.*stat functions?

non-blocking Unix.*stat functions?

[Vincenzo Ciancia]

Hi all,

in the process of building a multithreaded and up-to-date binding to the 
fuse (filesystem in userspace) library, I just noticed that unix.stat 
and friends are blocking operations (in the sense that they block other 
threads). Binding their unix counterparts using a [blocking] tag in 
camlidl would be easy, but could this perhaps be fixed in the standard 
library?

Thanks

Vincenzo

Re: [Caml-list] non-blocking Unix.*stat functions?

[David Brown]

On Thu, Oct 28, 2004 at 10:06:31PM +0200, Vincenzo Ciancia wrote:

> in the process of building a multithreaded and up-to-date binding to the 
> fuse (filesystem in userspace) library, I just noticed that unix.stat 
> and friends are blocking operations (in the sense that they block other 
> threads). Binding their unix counterparts using a [blocking] tag in 
> camlidl would be easy, but could this perhaps be fixed in the standard 
> library?

Well, in "ordinary" filesystems, stat and friends don't generally take very
much time, which is probably why they aren't blocking.

It wouldn't be hard to make them blocking, but you would have to copy the
pathname strings (since they could move while blocked).

Dave

Re: [Caml-list] non-blocking Unix.*stat functions?

[Vincenzo Ciancia]

On Thursday 28 October 2004 23:45, David Brown wrote:
> Well, in "ordinary" filesystems, stat and friends don't generally
> take very much time, which is probably why they aren't blocking.

Not quite, there is the cd reader; on a newly inserted cdrom for 
example: 

vincenzo@ronzinante vincenzo $ cd /mnt/cdrom
vincenzo@ronzinante cdrom $ time stat .
[...]

real    0m11.966s

this is also a problem with the Unix.LargeFile module of course. 

Vincenzo

-- 
Money for nothing, that's the way you do it
[Dire Straits]