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/ > >
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)
On Wed, Oct 27, 2004 at 05:32:51PM +0200, Reini Urban wrote: >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 don't know what you mean by the master process. It's easy to send signals to every cygwin process. You don't have to worry about threads. cgf
Re: sync(3)
Christopher Faylor schrieb:
On Wed, Oct 27, 2004 at 05:32:51PM +0200, Reini Urban wrote:
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 don't know what you mean by the master process.
the parent of some subprocesses.
exim or postgres or apache1 open a farm of subprocesses, which
eventually might want to sync() logfiles or mboxes.
It's easy to send signals to every cygwin process. You don't have to worry about threads.
good.
my private coverage:
time find /usr/src -name \*.c -exec grep -H sync \{\} \;
so far is unsuccessful.
The examples I found (exim, postgresql, uw-imap) all use fsync() (of
course). apache doesn't use fsync/sync (logs) at all.
But I didn't check the more likely candidates, perl/python/... or simple
small servers yet.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
