Multithreading
Daniel Salama
dsalama at user.net
Sat Mar 26 13:15:19 UTC 2005
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
>
>
More information about the Squeak-dev
mailing list
|