On Fri, 18 Mar 2005 07:57:25 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
The guarantee that we want to make is certainly stronger: if the
threads all read from the same file, each will get a series of chunks.
The guarantee is that it is possible to combine the chunks in a way to
get the
On Fri, 18 Mar 2005 07:57:25 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Writing down all these properties does little good, IMO. This includes
your proposed property of file reads: anybody reading your statement
will think of course it works this way - why even mention it.
The thingsa
On Thu, Mar 17, 2005, Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write are atomic by virtue of fread
and fwrite being atomic.
Uncle Timmy will
On Thu, 17 Mar 2005 16:25:44 -0500, Aahz [EMAIL PROTECTED] wrote:
On Thu, Mar 17, 2005, Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write are
On Thu, 17 Mar 2005 23:04:16 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write are atomic by virtue
On Thu, 17 Mar 2005 17:13:05 -0500, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy Hylton]
Are the thread semantics for file objecst documented anywhere?
No. At base level, they're inherited from the C stdio implementation.
Since the C standard doesn't even mention threads, that's all
On Thu, Mar 17, 2005, Tim Peters wrote:
I think Aahz was on target here:
NEVER, NEVER access the same file object from multiple threads, unless
you're using a lock.
And here he went overboard:
And even using a lock is stupid.
ZODB's FileStorage is bristling with locks
Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere?
Literally, the answer to your question is no.
I'm surprised that it does not, for example, guarantee that reads and
writes are atomic, since CPython relies on fread and fwrite which are
atomic.
Where is the
[Jeremy Hylton]
...
Universal newline reads and get_line() both lock the stream if the
platform supports it. So I expect that they are atomic on those
platforms.
Well, certainly not get_line(). That locks and unlocks the stream
_inside_ an enclosing for-loop. Looks quite possible for
On Thu, 17 Mar 2005 23:57:52 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Remember, you were asking what behaviour is *documented*, not what
behaviour is guaranteed by the implementation (in a specific version
of the implementation).
Martin,
I think you're trying to find more finesse in my
10 matches
Mail list logo
