juliapluto / malt.jl Goto Github PK

Some things are very performance-crucial, like Malt.remotecall_eval(:(1+1)). Can you use BenchmarkTools.jl and compare performance with Distributed? Can you put these scripts in the repository? <3

Distributed does this very well. With Base.atexit perhaps?

Malt consistently fails on windows because the behavior for half-open TCP connections differs from that of Linux and macOS.

Consider the following scenario:

• manager sends request
• manager awaits response
• worker sends response
• worker closes socket

Two things can happen:

• If the manager reads the response before the socket is closed, nothing happens.

• If the manager hasn't read the response, and the socket closes, windows will have the worker send an RST (reset signal) to the manager, causing an IOError in the manager.

Solution attempts:

1. Send another message to acknowledge that the socket can be closed. This won't work reliably in the presence of interrupt signals (in either the worker or the manager).
2. Don't close the sockets and let the GC handle it. This also doesn't work reliably either.

UPDATE: Solution 2 only fails when there's a signal that kills the process, using a dedicated message instead of an interrupt solves this issue, but it still cannot stop tight loops.

Related issues in Base

Maybe also related: libuv/libuv#3034

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

What happens when a worker throws an exception during a remote call? Can we add tests for this behaviour?

It would be awesome!

Something we sometimes use in Pluto is the ability to do a remote call, waiting for it to finish, but without having the result sent over the network. This is useful when the result of the computation uses types that are not defined in the main process, hence it cannot be serialized.

julia> using Distributed

julia> p = Distributed.addprocs(1) |> only
2

julia> Distributed.remotecall_eval(Main, p, :(1 + 1))
2

julia> Distributed.remotecall_eval(Main, [p], :(1 + 1))

julia> ans === nothing
true

Perhaps remote_do can return a Task that resolves to nothing when the call finishes?

In the terminal, Ctrl+C will interrupt some code, like sleep(1000), but not number-crunching code like tight loops. For this, the Julia client has special code that checks for quickly repeating interrupt signals, which creates a "super interrupt":

In Pluto, we have the following code to repeat the Ctrl+C signal:

https://github.com/fonsp/Pluto.jl/blob/70a80786fe9f5c3fe1c6c1368eb937a7e0288305/src/evaluation/WorkspaceManager.jl#L615-L649

This sort-of works (not on Windows), but it will occasionally kill the entire Julia process.

Can you create an example of interrupting while true end using Malt.jl? Can you consistently repeat this multiple times in the same process? Maybe this can be included in the tests?

Maybe this could be included in Malt.jl API, like interrupt(worker; aggressive=true)?