[squeak-dev] Problem with fork

Mariano Martinez Peck marianopeck at gmail.com
Wed Jul 1 17:55:37 UTC 2009


On Wed, Jul 1, 2009 at 3:10 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Hi Mariano,
>     Smalltalk's scheduler is preemptive across priorities and co-operative
> within priorities, which is a well-chosen real-time scheduling policy giving
> precise control over processes.  Because all your processes have the same
> priority they don't preempt the first process and so they don't get to run
> until after the doit has executed and the system has returned to some idle
> loop state.  If instead you change your code to either use a higher
> priority, e.g. [...] forkAt: Processor activePriority + 1, or to use yield,
> e.g. [....] fork. Processor yield, then you'll be able to get your desired
> behaviour.
>

Eliot: Thanks for the reply. I think I am understanding a bit more. Let me
explain myself a bit more what I am actually trying to do. I have SqueakDBX
which uses FFI to call external functions of OpenDBX and do queries to
databases. If you use SqueakDBX in a webapplication, like seaside, you will
have like several forks using SqueakDBX. And that's exactly what I am trying
to simulate: multiples forks (in a webapp they would be users connected). I
am doing some benchmarks as I have some things to define (timeouts) and see
how they affect this situation.

My real code (of the benchmark) is something like this:

collect: aBlock

|semaphores|
semaphores := Array new: self amountOfForks.
1 to: self amountOfForks do: [ :index | semaphores at: index put: Semaphore
new ].

    1 to: self amountOfForks do: [:i |
        [
        mutex critical: [ times add: (MessageTally time: aBlock) ].
        (semaphores at: i) signal.
        ] forkAt: self benchPriority
    ].

    semaphores do: [:each | each wait ].

In this case, aBlock is a piece of code that does a big select.

During all the methods which are called in aBlock (SqueakDBX methods) there
are for example, FFI calls and several things more. Suppose all the forks
are with the same priority. My question is now when would the scheduler take
another one?  As OpenDBX supports Asynchronous queries I just ask using FFI
is the query if done or not and the function returns immediately. But, in
order to let another connection to do another query, what I do, in case the
query is not finished is:

(Delay forMilliseconds: 1000) wait

This piece of code will free that process and pass to another? if not, I
must add a yield ?

Thanks a lot for the help!

Mariano



>
>
> On Wed, Jul 1, 2009 at 7:41 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> Hi folks! I am doing some benchmarks and I having problems with fork (I
>> think).
>>
>> I have this method collect:
>>
>> collect
>> |semaphores tr|
>> semaphores := Array new: 10.
>> tr := ThreadSafeTranscript new.
>> tr open.
>> 1 to: 10 do: [ :index | semaphores at: index put: Semaphore
>> forMutualExclusion ].
>>
>>     1 to: 10 do: [:i |
>>         [
>>         tr show: 'one fork'; cr.
>>         (semaphores at: i) signal.
>>         ] fork
>>     ].
>>
>>     semaphores do: [:each | each wait ].
>>     tr show: 'all forks proccesed'; cr.
>>
>>
>> What I want is that the method collect returns when ALL of the forks
>> created inside, are finished. Obviously in my real code, I don't do a
>> transcript show: but another thing.
>>
>> I would expect something like this:
>>
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> one fork
>> all forks proccesed
>>
>> But the output is:
>>
>>
>> all forks proccesed
>> one fork
>> one fork
>> one fork
>> one forkone fork
>> one fork
>> one fork
>> one forkone fork
>> one fork
>> one fork
>> one forkone fork
>>
>> So, I guess it isn't working :(   I don't know too much about forks so any
>> help is welcome!
>>
>> can be a problem with  ThreadSafeTranscript  ? If so, how could I test if
>> my code is working as expected ?
>>
>> Thanks,
>>
>> Mariano
>>
>>
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090701/028e4c0d/attachment.htm


More information about the Squeak-dev mailing list