Boris,

I thought about forking this somehow (didn't know how, but would have 
given it a shot). The problem is that I might have misinterpreted 
something I read in the book "Smalltalk and Object Orientation: an 
Introduction" by John Hunt. It read (from Chapter 31 - Concurrency in 
Smalltalk):

Quote:....................
Smalltalk has limited built-in support for concurrency. However, it 
does support Processes and Semaphores as primitive types. Other 
conventional inter-process communication and protection mechanisms such 
as SharedQueues and critical regions, are implemented in terms of these 
primitives. However, the processor scheduler (part of the virtual 
machine) implements a naive non-preemptive scheduling policy, with 
limited support for re-scheduling within a particular priority level. 
Further, once a high-priority process is running, no lower priority 
process will run until the high priority process suspends or 
terminates. For these reasons, the basic Smalltalk system contains only 
a few processes and typical applications using concurrency do not 
create more than a few tens of processes.
End Quote:.........................

Because of this, I thought that even if I fork it, it may not 
necessarily run preemptively and gain little benefit from such action, 
since there may be other system processes running that could simply put 
mine to sleep. I will give it a try and see what happens and will 
comment back.

Thanks,
Daniel

On Mar 26, 2005, at 3:50 AM, Boris Gaertner wrote:

> "Daniel Salama" <dsalama at user.net> wrote:
>
>> Hi,
>>
>> I'm experiencing a bit of a problem with a simple task I'm doing. I'm
>> trying to read a file and print something in the Transcript window
>> while reading the file. The problem I find is that while Squeak is
>> reading the file, the VM dedicates 100% of its processor time to that
>> task.
>> On the same VM, I'm running Seaside, so while the VM is reading
>> the file, Seaside cannot render any pages. Any suggestions on how to
>> overcome this problem?
>
> Work with processes is advanced stuff - I really cannot explain
> that in 5 minutes. To give you a point to start, please try this:
>
> reader :=
>    [  | stream newLineChar line |
>     stream := FileStream readOnlyFileNamed: filename.
>     newLineChar := Character cr.
>     [stream atEnd]
>        whileFalse:
>         [line := stream upTo: newLineChar.
>          Transcript show: '.'.].
>      stream close.
>    ].
>
>   reader forkAt: Processor userBackgroundPriority.
>
> Rules:
>
> 1. To create a process, you have to encapsulate the
> code in a block.
> 2. To start the process, you send that block one of the
> messages  fork  or forkAt:
> 3. forkAt: allows you to assign a process priority, which
> normally desired. The instance protocol of class
> ProcessorScheduler contains methods to obtain process
> priorities (in message category 'priority names')
> Process is the sole instance of ProcessorScheduler
> in your image, so you can obtain process priorities
> from that object.
> 4. Processor userBackgroundPriority is a good choice
> for file handling in the background.
>
> When you try this example, you should find that
> your interface is not locked, but you may notice
> reduced responsiveness.
>
>
> Some advices are very necessary:
>
> 1. Archivate a copy of your image and its changes
> file before you begin to experiment with processes.
> 2. Do not try to save your image when processes that
> you have created are still running.
> 3. You can ignore advice no. 2, but at a price:
> It is often not possible to restart an image that was
> saved while user created processes were still running.
>
>
> Later
> Boris
>
>