[Vm-dev] Differentiate ProcessList and LinkedList - incomplete

David T. Lewis lewis at mail.msen.com
Sun Jan 10 16:55:23 UTC 2016

On Sat, Jan 09, 2016 at 05:40:09PM +0800, Ben Coman wrote:
> LinkedList is a generic concept but historically has been intimately
> coupled to Process scheduling.  While trying to make LinkedList API
> more generic, Pharo inadvertently introduced some problems with
> Processes, so we decided to copy LinkedList to ProcessList so this can
> remain specialised for Process scheduling, allowing LinkedList the
> opportunity to be more generic.
> Here is some history at fogbugz.pharo.com:
> Background...
>   Case 5602 "LinkedList at: index putLink: aLink"
>   Case 10273 "Cleaning Linked List API"
> Changes...
>   Case 15868 "Differentiate ProcessList and LinkedList"
>   Case 15871 "enable ProcessList"
>   Case 17277 "newSpecialObjectsArray should return a process list
> instead of a linked list at item 41"
> Semaphore rather intimately manipulates the process list, but it seems
> to have been missed as it still inherits from LinkedList.  Should it
> subclass ProcessList instead?

Based on the logic I see in #primitiveResume, I would expect that your
Semaphore class would need to inherit from ProcessList. You may also
need to update something in the special objects array (but that would
not affect the VM).

> I guess FreeTypeCacheLinkedList and Stack can remain where they are.
> So also a question for the Squeak, Cuis & Newspeak communities...
> There are various references to LinkedList in the VM [1].  Currently
> only in comments but there are hints down the track there could be
> more direct use.  So I am wondering how these groups would feel about
> aligning with Pharo on this change, so the comments in the VM can be
> updated accordingly?
> cheers -ben
> [1] https://git.io/vuQQk

Eliot may have more to say on this, but it looks to me like you are
basically just giving a different name to the linked list class that
will be used for process scheduling. I guess we could update some of
those comments in the VM classes, but I don't think it's a big issue
one way or the other.


More information about the Vm-dev mailing list