Smalltalk › Frameworks & Tools › Seaside › Seaside General

Re: Serving files -- correction

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Mark Miller

Re: Serving files -- correction

-------------- Original message --------------
From: Jason Johnson <[hidden email]>

> David Shaffer wrote:
> > tim Rowledge wrote:
> >>
> >> On 11-Oct-06, at 5:10 AM, David Shaffer wrote:
> >>
> >> Assuming I understand 'tread safe' in same way that you mean it, that
> >> isn't strictly correct. The problem is that the squeak model use
> >> separate positioning and read/writing calls. Thus is is quite
> >> possible (been there....) to have two processes referring to the same
> >> file and get
> >> procA -> position: a
> >> procB -> position: b
> >> procA -> read from position (which I thought was a!)
> >> boom.
> >>
> > I thought my meaning was the obvious one but now that I hear yours I'd
> > agree that I was wrong. So...(let's hope the second try is a charm)
> >
> > Just a point of clarification: file I/O on a single Stream is not
> > thread safe
>
> I know of no languages that are. If two processes are sharing the same
> data structure, then that will always have race conditions, unless every
> access is blocked by a Mutex (which, of course, you don't want).

I think I misinterpreted this message the first time through. What David was saying is that positioning the stream to a certain location in the file doesn't help, because the other thread may come along and position it somewhere else. I don't know enough to say whether the read operation also repositions the "file pointer" in the stream, so to speak. Anyway, like I was saying in my last message, it sounds like an intermediary architecture might be necessary to make different threads play nice together with the same file.

---Mark

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jason Johnson-3

Re: Serving files -- correction

[hidden email] wrote:
>
> I think I misinterpreted this message the first time through. What
> David was saying is that positioning the stream to a certain location
> in the file doesn't help, because the other thread may come along and
> position it somewhere else. I don't know enough to say whether the
> read operation also repositions the "file pointer" in the stream, so
> to speak. Anyway, like I was saying in my last message, it sounds like
> an intermediary architecture might be necessary to make different
> threads play nice together with the same file.

Except you don't need to. It is not necassary for two threads to play
nicely together with the same shared data structure. Just don't share
the data structures. Copy them, and if you need to comunicate to
another thread, do it with messages between the threads. Shared data =
bad. :) As far as I know, programming languages that specialize on
concurrent programming take this approach; shared data not allowed. Any
speed gain made by sharing is lost again by having to use locking
mechanisms and detect deadlocks, etc. (with the exception of the case
where the data is read only).

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside