Re: sync(3)
On Wed, Oct 27, 2004 at 04:36:17AM +0200, Reini Urban wrote:
Why is this a bad idea?
It's a very limited implementation of what sync is supposed to do but
maybe it's better than nothing.
A slightly more robust method would be to implement an internal cygwin
signal which could be sent to every cygwin process telling it to run
code like the below.
Of course, that isn't foolproof either since it doesn't affect
non-cygwin processes.
Do you have an assignment with Red Hat? If so, I'll check this in.
cgf
2004-10-27 Reini Urban [EMAIL PROTECTED]
* syscalls.cc (sync): Implement it via cygheap-fdtab and
FlushFileBuffers. Better than a noop.
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.345
diff -u -b -r1.345 syscalls.cc
--- syscalls.cc3 Sep 2004 01:53:12 - 1.345
+++ syscalls.cc27 Oct 2004 02:30:01 -
@@ -1082,6 +1082,24 @@
extern C void
sync ()
{
+ int err = 0;
+ cygheap-fdtab.lock ();
+
+ fhandler_base *fh;
+ for (int i = 0; i (int) cygheap-fdtab.size; i++)
+if ((fh = cygheap-fdtab[i]) != NULL)
+ {
+#ifdef DEBUGGING
+ debug_printf (syncing fd %d, i);
+#endif
+ if (FlushFileBuffers (fh-get_handle ()) == 0)
+{
+ __seterrno ();
+ err++;
+}
+ }
+ cygheap-fdtab.unlock ();
+ return err ? 1 : 0;
}
/* Cygwin internal */
Re: sync(3)
Christopher Faylor schrieb:
On Wed, Oct 27, 2004 at 04:36:17AM +0200, Reini Urban wrote:
Why is this a bad idea?
It's a very limited implementation of what sync is supposed to do but
maybe it's better than nothing.
A slightly more robust method would be to implement an internal cygwin
signal which could be sent to every cygwin process telling it to run
code like the below.
A signal looks better.
Maybe just to its master process, and all its subprocesses and threads?
I didn't check what fd's are actually stored in this heap.
On linux it should just ensure to flush the master inode block.
(makes sense for ext2 probably).
For NTFS Volumes this code would be okay as I read at MSDN.
Wonder what FAT will do. postgresql luckily uses fsync().
Maybe I should check which of our apps actually use sync(3).
exim out of my head.
Of course, that isn't foolproof either since it doesn't affect
non-cygwin processes.
Warning: I didn't test it. Maybe it would be better if someone else
would copy-paste it from close_all_files() as I did and test it.
I just had no guts yet to build my own dll.
Do you have an assignment with Red Hat? If so, I'll check this in.
Not yet, but I'll send a letter this week.
2004-10-27 Reini Urban [EMAIL PROTECTED]
* syscalls.cc (sync): Implement it via cygheap-fdtab and
FlushFileBuffers. Better than a noop.
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.345
diff -u -b -r1.345 syscalls.cc
--- syscalls.cc 3 Sep 2004 01:53:12 - 1.345
+++ syscalls.cc 27 Oct 2004 02:30:01 -
@@ -1082,6 +1082,24 @@
extern C void
sync ()
{
+ int err = 0;
+ cygheap-fdtab.lock ();
+
+ fhandler_base *fh;
+ for (int i = 0; i (int) cygheap-fdtab.size; i++)
+if ((fh = cygheap-fdtab[i]) != NULL)
+ {
+#ifdef DEBUGGING
+ debug_printf (syncing fd %d, i);
+#endif
+ if (FlushFileBuffers (fh-get_handle ()) == 0)
+ {
+ __seterrno ();
+ err++;
+ }
+ }
+ cygheap-fdtab.unlock ();
+ return err ? 1 : 0;
}
/* Cygwin internal */
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
RE: sync(3)
Well, I don't know if it's a bad idea, but FlushFileBuffers isn't guaranteed to do anything, and usually doesn't in the very instances that you need it most. But since sync(3) isn't guaranteed to do anything anyway, I guess it cancels out. I'd be sure to put comments in there saying that it really can't be relied on to do anything though. That will avoid people who come along later, see that sync looks like it should be working but isn't, and wonder what's wrong when there really isn't anything wrong. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban Sent: Tuesday, October 26, 2004 9:36 PM To: cygwin-patches mailing-list Subject: sync(3) Why is this a bad idea? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
