Usability of ARC/ORC in multi threaded code.

Just an idea about proving that variable graph is isolated. Maybe it could be done same way as out of bound runtime check is done, at runtime. In dev mode each ref variable has a field with thread id, and if that id is different from the current thread id when you touch that variable, the except

Usability of ARC/ORC in multi threaded code.

My English is not good. Still, I will try to explain what I had in my mind a bit more before I give up. I was answering these: > Araq: How can you assume a lock on the "root" Node? The compiler has no idea > about a "root" node > > PMunch: Indeed having a rule like "every local variable involv

Usability of ARC/ORC in multi threaded code.

Sorry, maybe it was 8-9 years ago when I've last time looked nim compiler source. I'm not exactly sure what I'm talking :) but I was thinking, you have to track and store information about every assignment, every access to that data in every module to make isolated work. Compiler then would need

Usability of ARC/ORC in multi threaded code.

> Just a thought. Ignore it if its indeed a stupid idea. You're describing `Isolated[T]` and `isolate` and we're trying to figure out how exactly it can work.

Usability of ARC/ORC in multi threaded code.

Most probably I'm being stupid here but cant you invent a new return type which cannot be assigned to a variable and cant be changed after returned from a proc? Then If threads:on, wouldnt it be possible to prove it that it is really not touched after its built in extra compiler pass ? proc bui

Usability of ARC/ORC in multi threaded code.

> I could whip up a realistic example, but without a working isolate system > it's hard to make sure the entire thing is correct. Yes, please do that. And it's not hard to do: Instead of `isolate` use `unsafeIsolate` to make the compiler shut up. And use valgrind/some sanitizer to make sure it'

Usability of ARC/ORC in multi threaded code.

> The result of the query borrows from the n parameter, and in theory the > lifetime dependency can avoid refcounting activity since it's assumed that > the lending parameter is reachable in the first place and the lent value > lifetime won't extend its lender's. Does this already prevent refcou

Usability of ARC/ORC in multi threaded code.

It's true, that example isn't a real word example. This was simply me trying different things to figure out where it broke, and then being surprised when it broke even if I didn't use the argument. The point is that right now `isolate` is so strict it's not useful at all. Since you can't pass in

Usability of ARC/ORC in multi threaded code.

Maybe what you say is true, maybe not. In your example proc createTree(hello: Test): Tree = Tree(left: Branch(data: "Hello"), right: Branch(data: "world")) Run The parameter `hello` is unused. This means it's not a realistic example. I keep asking for realis

Usability of ARC/ORC in multi threaded code.

Hmm, this "solution" considerably lowers the usability of the isolation system though.. Even the original issue just calls for better alias detection. If we had better alias detection the first of my two usecases would be possible today. With the rules changes to an `and` I think the isolation s

Usability of ARC/ORC in multi threaded code.

> Why did you have to change it? The original makes sense as long as the return > type can't alias any part of y It was done to fix and a better alias analysis might have achieved the same.

Usability of ARC/ORC in multi threaded code.

I don't know if it's the best example, but it's one example: The Node ref could be a global protected by a read/write lock.

Usability of ARC/ORC in multi threaded code.

I would wonder how more than one thread could have a reference to `Node` safely. It seems to create the scenario in question (the `query` call in relation to threads) we'd already have done something troublesome.

Usability of ARC/ORC in multi threaded code.

One question that's been on my mind regarding multithreading with ARC/ORC (without atomic refcount) is the relation with `lent T` return type. What I mean is that with [strict funcs](https://nim-lang.org/docs/manual_experimental.html#strict-funcs) we already have a nice way to prevent mutation

Usability of ARC/ORC in multi threaded code.

Why did you have to change it? The original makes sense as long as the return type can't alias any part of `y`

Usability of ARC/ORC in multi threaded code.

Ah, I think later in the implementation I had to change the `or` to an `and`. And the RFC wasn't updated. You're right!

Usability of ARC/ORC in multi threaded code.

Those where the rules I was referring to. In this case `x` is a function call, it is `.noSideEffect` (after the echo was removed) and has one argument, let's call it `y` here instead of reusing `x` like the RFC. `y` is not isolated as it is a ref type stored in a variable, but looking at the _o

Usability of ARC/ORC in multi threaded code.

>From the RFC: If `T` does not contain a `ref` or `closure` type, it is isolated. Else the syntactic structure of `x` is analyzed: * Atoms like `nil`, `4`, `"abc"` are isolated. * An array constructor `[x...]` is isolated if every element `x` is isolated. * An object constructor `Obj(x...)

Usability of ARC/ORC in multi threaded code.

I was thinking of the rules for isolation as laid out here: . According to that `f(...)` is isolated if it can't have side effects and the return type can't alias the input types. In my example I return a `Tree` type which can only alias `Branch` typ

Usability of ARC/ORC in multi threaded code.

Here is the PR adding an experimental mm:atomicArc switch booting: 6.374s (--mm:arc --threads:on) 7.107s (--mm:atomicArc --threads:on)

Usability of ARC/ORC in multi threaded code.

Question about CPS, does it work in single threaded mode? As just this, even without multicore support just the CPS working, would be already a huge deal.

Usability of ARC/ORC in multi threaded code.

Works just fine: import std / [json, isolation] import threading / channels type Test = ref object data: string Branch = ref object data: string Tree = ref object left, right: Branch var chan = newChan[Tree]() var thr

Usability of ARC/ORC in multi threaded code.

Oh that was just something I threw in to actually use the object at all. It isn't able to isolate it even if you don't use the object.

Usability of ARC/ORC in multi threaded code.

`echo hello.data` makes your proc have a side effect and in general side effects could write to globals so `isolate` prohibits it.

Usability of ARC/ORC in multi threaded code.

Ooh, I hadn't considered that the return of a complex proc could be isolated. That does indeed help matters. I modified your initial example to use a proc which generates a JSON object given a number and a string and it worked fine. But for my example it still doesn't work. Looking at the list o

Usability of ARC/ORC in multi threaded code.

> Would the use of in-process sockets result in the same problems ( ZMQ , NNG ) > ? Yes, the channel implementation is not important here.

Usability of ARC/ORC in multi threaded code.

Sorry if my question is way off, as I understand only small parts of this discussion. Would the use of in-process sockets result in the same problems ( [ZMQ](http://api.zeromq.org/2-1:zmq-inproc) , [NNG](https://nng.nanomsg.org/man/v1.3.2/nng_inproc.7.html) ) ?

Usability of ARC/ORC in multi threaded code.

I think creating an example app for Actor runtime showcasing features and problems may help. As defining a problem clearly already half a solution :). CPS may be one of such requirement, as it makes no sense for Actor platform that blocks threads on IO, and mixing async with actors is too compli

Usability of ARC/ORC in multi threaded code.

> The only way to move data to another thread is by passing it through > unsafeIsolate(). As a programmer I make a lot of stupid mistakes all the > time, one of which might be assuming that my data is isolated, while in > reality it is not. This will now result in an unsafe program that crashes

Usability of ARC/ORC in multi threaded code.

> You asked for an example, which I provided - apologies if that does not > answer your question. I wanted to see an example that shows some client code that uses your actors framework but isn't safe because of the current non-atomic ARC in subtle ways. Maybe because the client code moves betwe

Usability of ARC/ORC in multi threaded code.

You asked for an example, which I provided - apologies if that does not answer your question. I think I provided a valid example though, which is about safety. The only way to move data to another thread is by passing it through `unsafeIsolate()`. As a programmer I make a lot of stupid mistakes

Usability of ARC/ORC in multi threaded code.

> Except of course that the only way to do this is by calling the function > unsafeIsolate(), which is unsafe. We're running in circles now. And you didn't answer my questions either. If your data is not isolated no amount of type system voodoo that can prove isolation is gonna change anything.

Usability of ARC/ORC in multi threaded code.

Some times I wish there was a `safe ref object` that gave us Java or C# semantics. Not every ref needs to be safe, just the ones passed between threads. It ok to take a little performance hit by always having a lock around ref inc/dec and cycle scan.

Usability of ARC/ORC in multi threaded code.

> So fix by using a single > lock, it doesn't imply anything for ARC/ORC's usablity in a multi-threaded > setting. I am unsure there is any bug to begin with. 2-lock design significantly reduce contention and has been peer-reviewed and implemen

Usability of ARC/ORC in multi threaded code.

The problem is not in my actors or in any other code I wrote, but has to do with whatever the user might want to send through a channel. My example would be just the same as your example: just two threads and a single channel. No different from sending messages to actors through mailboxes. At t

Usability of ARC/ORC in multi threaded code.

It should be solid if the underlying primitives (locks) work as intended, as the implementation is pretty basic. Though, it's not basic enough, in my opinion, as it's a stripped down version of a more complex implementation with some remnant showing through, and I'd like to trim it down further.

Usability of ARC/ORC in multi threaded code.

> As far as I can tell, the language has no way of safely and reliably > verifying that any data being sent to a different thread (using channels or > any other method) is isolated. Well but `isolate` does exactly that. Can we make the analysis smarter to allow for more programs to be written?

Usability of ARC/ORC in multi threaded code.

> It is inevitable that client code will trigger ARC problems when using my > actors runtime. And I do not know how to solve this. this is the point I am > trying to make. Ok, so please show me an example.

Usability of ARC/ORC in multi threaded code.

> You already mentioned unsafeIsolate() in your snippet, which is just casting > the value to isolated[T], without actually checking if this is the case. But > now you're on your own - your code might work today but fail in interesting > ways ten months from now. The programmer now has the respo

Usability of ARC/ORC in multi threaded code.

@araq: " _The real question is how hard it is for client code to avoid triggering (non atomic) ARC problems when using your actors runtime_ " It is **inevitable** that client code will trigger ARC problems when using my actors runtime. And I do not know how to solve this. _this_ is the point I a

Usability of ARC/ORC in multi threaded code.

Thanks @zevv for the nice summary! I'm sure you will excuse my more positive, totally biased take on your work: > The Actors project is more or less complete, and is in a works-for-me state, > but I must admit that I have not actually used it for very much after I got > it to work; For those in

Usability of ARC/ORC in multi threaded code.

Just played around a bit with your example and unless I create the object entirely within the isolate call it doesn't work. This really limits what you're able to do with this since I can't create stuff outside the isolate call and then isolate them after the fact, and I'm not able to isolate so

Usability of ARC/ORC in multi threaded code.

@araq: Your example is demonstrating moving a _constant_ tree around has never been easier. It is showing the happy path because `isolate()` is able to take your const JSON tree and isolate it; when trying to pass anything else, `isolate()` is no longer able to do the job and will tell you `exp

Usability of ARC/ORC in multi threaded code.

So fix by using a single lock, it doesn't imply anything for ARC/ORC's usablity in a multi-threaded setting.

Usability of ARC/ORC in multi threaded code.

Moving a tree around has never been easier: import std / [json, isolation] import threading / channels var chan = newChan[JsonNode]() var thr: Thread[void] proc worker() {.thread.} = var x: JsonNode chan.recv(x) # somebody should fix this API...

Usability of ARC/ORC in multi threaded code.

Is the channels module actually thread safe though? . If this does indeed work without any leaks or other subtle issues then it's great news!

Usability of ARC/ORC in multi threaded code.

Very interesting writeup! The actor system you describe is exactly the kind of threading story which would really help Nim. A programming language which in 2023 doesn't have anything easier than manual locking and such isn't exactly a great look. Unfortunately it sounds like Nim currently fights

Usability of ARC/ORC in multi threaded code.

I agree that Valgrind can help a lot. But the code you write that can cause memory errors should be minimal. Not only that, but I recommend writing a minimal prototype program that tests the concepts on their own. Make sure this minimal program works fine without errors or leaks, then transfer t

Usability of ARC/ORC in multi threaded code.

(I indented to post the message below as a reply to the recent "Is ORC considered production ready" thread, but it grew much longer than I expected and I think it might deserve a separate thread. Note that I often consider myself not smart enough to write proper multi-threaded code, so the text