Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Threads #28

Closed
LucaGabi opened this issue Jul 19, 2018 · 2 comments
Closed

Threads #28

LucaGabi opened this issue Jul 19, 2018 · 2 comments

Comments

@LucaGabi
Copy link

Hi,

Dose this also offer support for threading as Nashorn ?
@wirthi
Copy link
Member

wirthi commented Jul 20, 2018

Hi Luca,

Graal JavaScript does not allow unlimited thread access in JS code like Nashorn. That is inherently insecure and can lead to unmanagable synchronisation problems (data races) everywhere.

We do however support several JavaScript engines being started from different threads, that communicate on their respective thread with Java code (where you can interact and do the syncronization properly). See https://github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md#multithreading for more information or #16 for some technical discussion.

Best,
Christian

@wirthi
Copy link
Member

wirthi commented Jul 20, 2018

I'm closing this issue. If you have a concrete problem that you cannot solve with the information provided above, please re-open this issue or create a new one.

Thanks,
Christian

@wirthi wirthi closed this as completed Jul 20, 2018
graalvmbot pushed a commit that referenced this issue Sep 1, 2021
@targos
deps: V8: cherry-pick 482e5c7750b3
aff53dd 
Original commit message:

    Merged: [wasm-simd] Fix loading fp pair registers

    We were incorrectly clearing the high reg from the list of regs to load.
    The intention was to prevent double (and incorrect) loading - loading
    128 bits from the low fp and the loading 128 bits from the high fp.
    But this violates the assumption that the two regs in a pair would be
    set or unset at the same time.

    The fix here is to introduce a new enum for register loads, a nop, which
    does nothing. The high fp of the fp pair will be tied to this nop, so as
    we iterate down the reglist, we load 128 bits using the low fp, then
    don't load anything for the high fp.

    Bug: chromium:1161654
    (cherry picked from commit 8c698702ced0de085aa91370d8cb44deab3fcf54)

    (cherry picked from commit ffd6ff5a61b9343ccc62e6c03b71a33682c6084d)

    Change-Id: Ib8134574b24f74f24ca9efd34b3444173296d8f1
    No-Try: true
    No-Presubmit: true
    No-Tree-Checks: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2619416
    Commit-Queue: Zhi An Ng <[email protected]>
    Reviewed-by: Clemens Backes <[email protected]>
    Cr-Original-Commit-Position: refs/branch-heads/8.8@{#28}
    Cr-Original-Branched-From: 2dbcdc105b963ee2501c82139eef7e0603977ff0-refs/heads/8.8.278@{#1}
    Cr-Original-Branched-From: 366d30c99049b3f1c673f8a93deb9f879d0fa9f0-refs/heads/master@{#71094}
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649176
    Reviewed-by: Victor-Gabriel Savu <[email protected]>
    Commit-Queue: Achuith Bhandarkar <[email protected]>
    Cr-Commit-Position: refs/branch-heads/8.6@{#55}
    Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1}
    Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472}

Refs: v8/v8@482e5c7

PR-URL: nodejs/node#38275
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Jiawen Geng <[email protected]>
Reviewed-By: Shelley Vohr <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wirthi @LucaGabi