Closed Bug 490531 Opened 15 years ago Closed 6 years ago

Erlang-style process primitives

Categories

(Tamarin Graveyard :: Virtual Machine, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: lhansen, Assigned: kpalacz)

References

Details

(Whiteboard: has-patch)

Attachments

(3 files, 17 obsolete files)

52.07 KB, patch
edwsmith
: review+
Details | Diff | Splinter Review
21.27 KB, patch
edwsmith
: review+
Details | Diff | Splinter Review
867.19 KB, patch
Details | Diff | Splinter Review
Code to implement Erlang-style shared-nothing message passing on Tamarin, using one real thread per process in a shared memory where the block manager (GCHeap) is shared but each thread is running a separate VM instance.

More elaborate models, eg Google Gears style worker pools, can be built on top of this.

Documentation in shell/Process.as, code in shell/ProcessClass.{h,cpp}.

Note, you must manually rebuild the shell toplevel ABC code if you want to play with this patch.
Attached file crude example, part 1 (obsolete) —
Attached file crude example, part 2 (obsolete) —
Attached file crude example, part 3 (obsolete) —
part 1 is mainloop.as, which is included into part 2 (master.as) and part 3 (slave.as).  compile the master and the slave, then start the shell with master.abc.  ^C to exit.
Attachment #374936 - Attachment mime type: application/octet-stream → text/plain
Oops.  The patch appears to be non-functional following a merge and the test cases are actually slightly off (they use System. rather than Process. for the methods); I tested the wrong executable /and/ the wrong ABCs (sorry)...  So consider the code to be illustrative rather than running at this point.
Attachment #374933 - Attachment is obsolete: true
Attached file Crude example, reworked (obsolete) —
Attachment #374934 - Attachment is obsolete: true
Attachment #374935 - Attachment is obsolete: true
Attachment #374936 - Attachment is obsolete: true
Target Milestone: --- → Future
Assignee: nobody → lhansen
Status: NEW → ASSIGNED
Attachment #375002 - Attachment is obsolete: true
To do before any kind of review:

- move processClass from avmshell::ShellCore to avmplus::Toplevel
- move Process.as, ProcessClass.h, ProcessClass.cpp from shell/ to core/
- disentangle the avmshell dependencies is the process code, move the support
  into ShellCore and/or AvmCore
- fix the FIXMEs
User branch on asteam: /users/lhansen/redux-multicore
Obvious missing things now:

- a proper feature in avmfeatures.{as,h} instead of the hackery in avmbuild.h
  to control whether it's turned on
- probably #ifdefs around some of the changes in core/
- at least test compile on linux to ensure that it's not hopelessly
  mac-centric
- at least reviews sufficient to convince ourselves we're not breaking any
  current functionality
Linux compile fixes are in: redux-multicore changeset:   4136:ef0fe571f7c1
Feature fixes are in: redux-multicore changeset:   4137:d71e8f35d875
Attachment #375003 - Attachment is obsolete: true
Attachment #422585 - Attachment is obsolete: true
Attached patch /test/multicoreSplinter Review
More FYI than really a review request, but I figure I should have formal approval before landing.
Attachment #434690 - Flags: review?(kpalacz)
Attachment #434690 - Flags: review?(edwsmith)
Attached patch /doc/multicoreSplinter Review
Again, FYI but formal approval requested.
Attachment #434693 - Flags: review?(kpalacz)
Attachment #434693 - Flags: review?(edwsmith)
Attached patch Process and Shm objects (obsolete) — Splinter Review
There's a peculiarity with these in that they are present even when we are not building with process support.  The reason is that that's how our builtin.py step works: there's no conditional generation of the builtins depending on what preprocessor macros are in effect, and since there are native methods the generated .cpp files will reference the Process and Shm types.  It's not a big deal but we might want to address this by and by.
Attachment #434696 - Flags: review?(kpalacz)
Attachment #434696 - Flags: review?(edwsmith)
Attached patch Changes to /core and /shell (obsolete) — Splinter Review
Attachment #434697 - Flags: review?(kpalacz)
Attachment #434697 - Flags: review?(edwsmith)
In addition to these patches, new files must be added to Xcode and Visual Studio project and core/builtin.py and core/avmfeatures.as must be run to generate sundry updated files.
Whiteboard: Has patch
Assignee: lhansen → kpalacz
[doc,test]/multicore should probably be renamed "processes"

We got bitten by adding Vector to the empty package, and Process/Shm are possibly likely to collide too.   The workaround for Vector was to put them in the __AS3__.vec package, which ASC opens implicitly based on project/commandline settings.

(more soon)
BuiltinTraits.cpp/h, Toplevel.cpp/h, avmplus.h - need VMCFG guards around new classes?

If its infeasible to exclude new Process/Shm classes from builtin.abc when the process feature is disabled, then i suggest moving them to shell_toplevel.abc (without any namespace changes).  just dont want them to leak into shipping code accidentally.  maybe: add a commandline switch to core/builtin.py?

As a first pass, that's all I saw that would need tweaking before landing in tamarin-redux.  WIll review again in more detail soon.  (R+, adding F?edwsmith for the second review)
Attachment #434690 - Flags: review?(edwsmith) → review+
Attachment #434693 - Flags: review?(edwsmith) → review+
Attachment #434696 - Flags: review?(edwsmith) → review+
Attachment #434697 - Flags: review?(edwsmith) → review+
Attachment #434697 - Flags: feedback?(edwsmith)
Regarding isolating Process and Shm, I agree this is a concern but it is probably going to be a pain in practice because they're somewhat tightly intertwined with the VM core.  (It may also be that they need to go into a new package, flash.concurrency or somesuch.)  Not saying it can't happen, but that they were originally in Shell and were moved into Core to clear up coupling issues.
I buy that.  Do we agree we at least need some way to control them based on the process feature being enabled?  In BuiltinTraits/Toplevel/avmplus.h, ifdef is good enough.  in builtins.cpp/h/abc, we sort of run out of steam.

just brainstorming:

* as3 configuration variables could enable/disable them, but based on what?  avmfeatures.as would need to generate something that builtin.py reads and passes to asc

* builtin.py could compile the builtins both ways, and include both blobs, e.g. generate this:
builtin.cpp:
 #ifdef VMCFG_PROCESSES
    /* everything from builtin.cpp with them enabled */
 #else
    /* everything from builtin.cpp with them disabled */
 #endif

it may seem gross, but its only a couple lines of python, probably.
and it  doesn't scale to all features, but thats okay for the medium term.
nativegen.py does something like this to build all the thunks two ways, controlled by an #ifdef, without having to re-run nativegen twice.
Well, doing nothing is OK for the medium term.  After all it's redux, it won't ship in anything until next year :-)
Attachment #434690 - Flags: review?(kpalacz)
Attachment #434693 - Flags: review?(kpalacz)
Attachment #434696 - Flags: review?(kpalacz)
Attachment #434697 - Flags: review?(kpalacz)
Attachment #434697 - Flags: feedback?(edwsmith)
This is a snapshot of  work in progress, early feedback from anyone interested welcome. An the API front, Process objects encapsulate processes, and MessageChannels represent bidirectional communication between two processes. Communication is synchronous (no queuing) and passing of non-primitive data types are not supported yet.
Attachment #434696 - Attachment is obsolete: true
Attachment #434697 - Attachment is obsolete: true
(In reply to comment #23)
> Created an attachment (id=447871) [details]
> Significant reorganization of the API and implementation - work in progress.
> 
> This is a snapshot of  work in progress, early feedback from anyone interested
> welcome. An the API front, Process objects encapsulate processes, and
> MessageChannels represent bidirectional communication between two processes.
> Communication is synchronous (no queuing) and passing of non-primitive data
> types are not supported yet.

On a style note, do not use plain 'new' and 'delete' - they're not allowed in the player.  Use the mmfx_new etc macros.
Attached patch Updated work in progress. (obsolete) — Splinter Review
Moved API classes to shell, harmonized with new code in the patch for bug 555765, various small fixes.
Attachment #447871 - Attachment is obsolete: true
Blocks: 555765
No longer blocks: 555765
Depends on: 555765
Attached patch More work in progress (obsolete) — Splinter Review
Attachment #453289 - Attachment is obsolete: true
Attached patch work in progress, rebased (obsolete) — Splinter Review
Attachment #455772 - Attachment is obsolete: true
Attached patch reworked and rebased (obsolete) — Splinter Review
Attachment #481092 - Attachment is obsolete: true
Attachment #485068 - Attachment is obsolete: true
Attached patch update (obsolete) — Splinter Review
Rebased, cleaned up, isolate termination fixes, MessageChannel improvements.
Attachment #486711 - Attachment is obsolete: true
Attached patch another update (obsolete) — Splinter Review
Attachment #487588 - Attachment is obsolete: true
diff wrt 5560:fd3ee180e90e
Attachment #492850 - Attachment is obsolete: true
This would help me so much, I have a six-core machine, and sometimes when running intensive canvas websites the browser maxes out a core, but only one core.
Lars, Krzysztof, is this still relevant or obsolete given isolates work.
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Flags: flashplayer-bug-
Whiteboard: Has patch → has-patch
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: