stelios xanthakis wrote:
I think that when two threads write to the same fd without
syncronization, the result is not
deterministic anyway. In the case they are reading from the same fd,
even worse! (and therefore
the input cannot be useful to any serious algorithm)
Yes, but we are not talking ab
Jeremy Hylton wrote:
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 lik
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 thi
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
>
Jeremy Hylton wrote:
It sounds like the weakest intended behavior we have is the one Tim
reported: "provided the platform C stdio wasn't thread-braindead,
then if you had N threads all simultaneously reading a file object
containing B bytes, while nobody wrote to that file object, then the
total n
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
[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 diff
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 connec
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 wit
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, 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
[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
platform-dependent. POSIX defines thread semantics for file I/O, but
fat lot of go
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 no doubt agree with me: the se
Jeremy Hylton wrote:
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 a
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
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 wi
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.
I'm less sure what guarantees, if any, the other methods attempt to
17 matches
Mail list logo
