[Seaside] Serving files

[Jason Johnson]

mmille10 at comcast.net wrote:
> -------------- Original message --------------
> Agreed. It sounds similar to a classic readers-writers problem, where 
> you have multiple threads sharing a memory space, but this is with a 
> file. In effect, it sounds like when a process reads from a file it 
> also writes a new file position to the file I/O process, in effect 
> "changing the buffer" for other processes that also want to read from 
> it. I must admit I'm a total newbie to Squeak (I'll be brushing up on 
> it soon), but from both of your descriptions it would appear that the 
> only way to, in effect, make it thread safe would be to use mutexes, 
> as Jason said, short of changing the VM, which has been mentioned earlier.

Yea, the problem is, each thread starts with a snap-shot which they 
change, but have no way of letting the other guys know it changed.  You 
get the same thing if you edit a file on a server at the same time as 
someone else.  They save, then you save.  Their work is completely lost 
at that point since your editor program took a copy of the file before 
it started.

But this isn't a real problem actually.  No one should be trying to 
share data structures between thread's by default.  I don't think anyone 
is now.  David was just clarifying that trying to isn't safe, and I was 
just pointing out that this isn't *smalltalk* specific.  It isn't safe 
in C/C++/Java/Oz or anything else.  If someone really *does* want to 
share a data structure across threads (for speed or something) then they 
have to know what they are doing and protect it with a mutex or something.
>  
> An idea might be to have a "thread file handler" architecture, that 
> each thread in Squeak could use. Perhaps this could be written in 
> Smalltalk. It would act as an intermediary between the thread and the 
> file I/O process. It's whole job would be to handle file input, keep 
> track of each thread's position in the file, and implement the mutex 
> action. To make it an effective tool one would have to implement 
> "time-sharing" of the input--limit a thread's bandwidth in terms of 
> bytes read over a period of time. So each thread would get some 
> file input time, rather than one thread hogging the file until it's 
> read all the way through it.
>  
> A possible workaround to the problem discussed earlier would be to 
> have a master copy of the file, and any time a thread needed it, it 
> would generate a unique ID, make a copy of the original to a filename 
> whose name is that ID, and then read from the copy, rather than the 
> original, and delete the copy when it was done.
>  
> I assume this just has to do with multiple processes reading from the 
> same file, not multiple processes trying to read from different files, 
> correct?

Well, as I said above, there is no problem to solve here with the files, 
per se.  However, you do bring up a good point:  perhaps the smalltalk 
VM should get further into the "OS business" then it is now. What I mean 
by that is: right now it sounds like there are problems certain calls 
blocking the VM, etc.  Perhaps primitives should be seen in the same way 
as the OS sees a system call; if a thread makes a syscall or primitive 
call it gets put to sleep, the OS (or VM in this case) makes an async 
request (exactly how disk access works at the OS level) and gets some 
kind of notification when it is complete, fills in the data where the 
thread expects it and wakes it up again.