On Fri, 13 Mar 2009 11:27:54 am R. David Murray wrote:
> Seriously, though, the point is that IMO an application should not be
> calling fsync unless it provides a way for that behavior to be
> controlled by the user.
An admirable approach, but also a sweeping generalisation. Who is your
expected
On Fri, 13 Mar 2009 07:25:59 am Antoine Pitrou wrote:
> R. David Murray bitdance.com> writes:
> > By the way, I would not like to see python programmers encouraged
> > to make the same mistake that sqlite3 made. The decision about how
> > aggressive to be on flushing data to disk should be in the
On Fri, 13 Mar 2009 08:01:27 am Jim Jewett wrote:
> On 3/12/09, "Martin v. Löwis" wrote:
> >> It is starting to look as though flush (and close?) should take an
> >> optional wait parameter, to indicate how much re-assurance you're
> >> willing to wait for.
> >
> > Unfortunately, such a thing woul
On Thu, 12 Mar 2009 at 22:09, "Martin v. L?wis" wrote:
Let me try some examples.
Suppose I'm running my applications on a laptop and I don't want the
disk to be spinning continually while I work. I'm willing to take the
risk of data loss in order to extend my battery life.
So when you select
On Thu, Mar 12, 2009 at 08:25:59PM +, Antoine Pitrou wrote:
> However, I also think that any parameter to flush() or close() is a bad idea,
> since it can't be used when flushing and closing is implicit. For example when
> the file is used in a "with" statement.
I think the existing os.fsync()
On Thu, 2009-03-12 at 20:25 +, Antoine Pitrou wrote:
> I disagree. The user usually does not know which kind of flushing is needed in
> order for his data to be safe. Actually, he probably doesn't even know what
> flushing means, and that files are ever "closed".
>
> However, I also think that
Jim Jewett wrote:
On 3/12/09, "Martin v. Löwis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating s
On Thu, Mar 12, 2009 at 4:09 PM, "Martin v. Löwis" wrote:
> So when you select "Save" in your application, would you like the data
> to be saved, or would you accept that they get lost? If the latter,
> what kind of interaction would you perform with your application to
> indicate that you *do* wa
Jim Jewett wrote:
> On 3/12/09, "Martin v. Löwis" wrote:
>>> It is starting to look as though flush (and close?) should take an
>>> optional wait parameter, to indicate how much re-assurance you're
>>> willing to wait for.
>
>> Unfortunately, such a thing would be unimplementable on most of today
On Thu, 12 Mar 2009 at 17:01, Jim Jewett wrote:
On 3/12/09, "Martin v. L?wis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable
> Let me try some examples.
>
> Suppose I'm running my applications on a laptop and I don't want the
> disk to be spinning continually while I work. I'm willing to take the
> risk of data loss in order to extend my battery life.
So when you select "Save" in your application, would you like the d
On 3/12/09, "Martin v. Löwis" wrote:
>> It is starting to look as though flush (and close?) should take an
>> optional wait parameter, to indicate how much re-assurance you're
>> willing to wait for.
> Unfortunately, such a thing would be unimplementable on most of today's
> operating systems.
W
On Thu, 12 Mar 2009 at 20:25, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
By the way, I would not like to see python programmers encouraged to make
the same mistake that sqlite3 made. The decision about how aggressive
to be on flushing data to disk should be in the hands of th
R. David Murray bitdance.com> writes:
>
> By the way, I would not like to see python programmers encouraged to make
> the same mistake that sqlite3 made. The decision about how aggressive
> to be on flushing data to disk should be in the hands of the _user_, not
> the application.
I disagree. T
On Thu, 12 Mar 2009 at 20:56, "Martin v. L?wis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating syst
> It is starting to look as though flush (and close?) should take an
> optional wait parameter, to indicate how much re-assurance you're
> willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating systems.
Regards,
Martin
__
16 matches
Mail list logo
