Let's Remove the Global Interpreter Lock

Re:Let's Remove the Global Interpreter Lock by kllrnohj on Monday August 14, 2017 @04:01PM (#15012281)

You seem to be conflating moving with sharing. Moving between threads is always free[1] regardless of if it's mutable or immutable, and there's no concurrency issues at all since it's a move.

Move means the sender no longer has a reference. As in, std::move, rust's ownership transfer, webworker's transferables, etc...

1: Yes there's a single synchronize point where the handoff happens, but this is part of sending a message at all. It's also independent to the size & complexity of the payload itself when we're talking multi-threaded instead of multi-process. You have that exact same sync point that costs the exact same regardless of whether your message consists of a single byte or a multi-gigabyte structure.

[ Parent | on HN ]

Re:Let's Remove the Global Interpreter Lock by breatheoften on Monday August 14, 2017 @08:34PM (#15014358)

Ah I see -- Can you actually describe ownership in python sufficiently well to be able to describe this move operation for any useful python data structures?

[ Parent | on HN ]

Re:Let's Remove the Global Interpreter Lock by kllrnohj on Tuesday August 15, 2017 @10:51AM (#15018702)

Generically ownership is simply who has a reference to the object.

So if a.foo = b, then a 'owns' b. A 'move' is simply handing a different object the reference, then dropping your own reference. For example:

  a.foo = b // a 'owns' b
  c.foo = a.foo // a & c share b, however if the next line is:
  a.foo = None // a has 'moved' b to c, since c now has the only reference to b.

Some languages have codified this to make the contract part of the language, but it doesn't need any first-class language support. It's just a pattern at the end of the day.

[ Parent | on HN ]