Issue with process.st and preemptive mode

Hi all,

for the last few hours I am enjoying a flight with power outlets and I
was poking the VM with pre-emtpive mode.

The symptom is that make check will just hang. I have traced it down to
one of the Evals.

Eval [
    | queue stop s |
    queue := SharedQueue new.
    stop := false.
    s := Semaphore new.
    [ s signal.
      [ stop ] whileFalse: [ queue nextPut: true. Processor yield ] ] fork.
    s wait.
    [ (Delay forMilliseconds: 500) wait. stop := true ] fork.
    [ stop ] whileFalse: [ queue nextPut: false. Processor yield ].
]

I have not found a solution yet but I feel like sharing my observations.
It seems to work fine when the the Delay thread is exiting first (of
course it has to) and then the mainThread (as this appears to make us
quit). It is going horrible wrong when one of the threads have evaluated
the whileFalse: [] and the next executiog to execute is Processor yield,
then the Delay thread is exiting, the other thread as well and then the
"Processor yield" will suspend the whole VM as it would schedule it self.

Is that the expected behaviour? Should there be some code to check if a
process has recently exited and then not yield the Process but cycle
it once more?


regards
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/10/2010 11:40 AM, Holger Hans Peter Freyther wrote:
> Is that the expected behaviour? Should there be some code to check if a
> process has recently exited and then not yield the Process but cycle
> it once more?

Yes, it looks like that.  Check highest_priority_process:


               /* If there's only one element in the list, discard this
                  priority.  */
               processList = (gst_semaphore) OOP_TO_OBJ (processListOOP);
               if (processList->firstLink == processList->lastLink)
                 continue;

maybe you want to test is_process_terminated too somewhere?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/11/2010 06:41 PM, Paolo Bonzini wrote:

>
> Yes, it looks like that.  Check highest_priority_process:

>
> maybe you want to test is_process_terminated too somewhere?

Hi,

I had some time to look into it some more. The first hack I tried to
kind of verify my previous claim was to start a idle task that executes
Delay. This way the yielded process will be resumed... I will now try to
understand the processList of the Processor.


One stupid question, when will terminated processes be
removed/destroyed/deleted from the system? I have seen
Process>>primTerminate (or such) but this does not seem to remove the
Process?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> One stupid question, when will terminated processes be
> removed/destroyed/deleted from the system? I have seen
> Process>>primTerminate (or such) but this does not seem to remove the
> Process?

A suspended process is removed from the process list.  A terminated
process is simply a suspended process with a nil suspendedContext (so
it cannot be resumed).

The processes are destroyed/deleted through normal GC.  Running
processes are never GCed, because they're accessible via Processor
which is one of the VM's roots.  But non-running processes can be
garbage collected even before they've been terminated if:

1) they are suspended

2) they are waiting on a semaphore that is GCed itself.

as long as the process is not reachable otherwise.  In both cases
#ensure: blocks etc. won't be executed, which makes suspending
processes usually a very bad idea unless you want to manage your
memory as you would in C. :-)

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk