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