This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)

Pierre A. Humblet wrote:

On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote:

On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote:

Beware, I found this:
2000-05-19 DJ Delorie <>
* libc/include/stdio.h: no getc/putc macros for cygwin; causes
compatibility issues with different dll versions
so you may need to recompile when updating cygwin.

Also wouldn't that work around the file locks that were ostensibly put
there for a reason?

That crossed my mind. But there is no file lock in the macro, which is
used by systems other than cygwin. How do they manage it?
I also assume that single threaded programs don't need the lock.

Is the lock to ensure that normal POSIX append semantics are obtained when two processes are writing to the same file? Normal win32 behaviour would tend to overwrite whatever had been written by the other process unless the file is only opened once and then the handle duplicated (very messy). So if you want append mode to work correctly (i.e. Unix style), then you always have to use file locks around any file write operation that is expected to be atomic. The locks could be avoided for non append mode writes and where the file has been exclusively locked anyway.

Single thread programs will need the lock just as much as multithread. You can only avoid it if you just a single process (with just one thread),.

Mark Thornton

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]