[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #33138] .PARLLELSYNC enhancement with patch

From: Eli Zaretskii
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Fri, 19 Apr 2013 12:36:48 +0300

> Date: Fri, 19 Apr 2013 00:06:52 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> > > > Indeed, as you suggested earlier, it might be useful to use the main
> > > > part of open_tmpfile() (i.e. without the fdopen()), though we'd have
> > > > to manually remove the file then. On Unix, we could unlink it right
> > > > after opening (since we never need the filename again, unlike the
> > > > other users of open_tmpfile()). On Windows, though, this might need
> > > > to be delayed, AIUI.
> > > 
> > > You can do that on Windows as well, just not if you use open/creat to
> > > create the file.  You need to use the Windows file APIs with options
> > > that are not exposed to Posix-style functions like open.
> > 
> > Can you get an fd from a file opened this way?
> Yes.
> > If so, it should be alright, it could all be encapsulated in
> > open_tmpfd().
> I'm not sure it's worth the hassle.  Using tmpfile is so much easier
> (if it works, which is to be determined).

Initial investigation indicates that tmpfile should do the job just
fine: the file is deleted only when the last descriptor for it is
closed.  That includes any duplicated descriptors.

As for fcntl, F_SETLKW, and F_GETFD, they will need to be emulated.
In particular, it looks like LockFileEx with LOCKFILE_EXCLUSIVE_LOCK
flag set and LOCKFILE_FAIL_IMMEDIATELY flag cleared should do the
job.  I will need to see how it works in reality, though.

Is there a simple enough Makefile somewhere that could be used to test
this feature, once implemented?

Also, where is the best place to put the emulated Posix functions?
Some new file in w32/compat/?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]