sabre icon indicating copy to clipboard operation
sabre copied to clipboard

Published 20 hours ago • verified publisher icon spy16

Support goroutine invocation

Open lthibault opened this issue 4 years ago • 4 comments

I'd like to be able to call a function in a separate goroutine using the following syntax:

(go
  (expensive-function arg1 arg2))

A few design considerations:

  1. Separate goroutines might switch to different namespaces (by calling (ns 'some.other.namespace)).
  2. I would like to implement something a Clojure-style value/reference distinction in my own project. In particular, I am considering something like Clojure's Var, which provides a thread-local symbol mapping facility.

What are your thoughts? I think goroutine support is a must-have, but any idea on how the above items might work? Thread-local storage is usually achieved with context.Context in Go, so I'm thinking that Sabre's goroutines should probably have some soft of context attached.

To be clear: I don't think Sabre should support item 2. It would force us to provide immutable data structures ( I think ... 🤔), which adds a lot of complexity and fails to leverage native Go structures like map and slice (which is kind of the point of Sabre). Rather, I think Sabre should be flexible enough that I can implement these in my own language.

lthibault avatar Feb 25 '20 19:02 lthibault

goroutine support is a must-have

Agreed.

Currently none of the Sabre value types are designed with concurrency safety in mind. So will have to get that done first.

I don't think Sabre should support item 2. It would force us to provide immutable data structures

Yep. It sounds very tempting and interesting, but I don't think it's something Sabre should do at the moment..

Need to think about thread local storage..

spy16 avatar Feb 26 '20 04:02 spy16

Currently none of the Sabre value types are designed with concurrency safety in mind. So will have to get that done first.

Couldn't we take the Go approach and leave proper synchronization to the user?

Exposing thread-safe value types seems to be at odds with our goal of simplicity.

lthibault avatar Feb 26 '20 08:02 lthibault

In most cases yes. But the special handling done for special forms modifies lists in place right now which user will not be able to synchronize.. but I do have a different approach for the special form handling which will fix this..

spy16 avatar Feb 26 '20 12:02 spy16

@spy16 I'm slowly approaching the point at which I'd like to start working on this. What did you have in mind for fixing the special-form issue?

lthibault avatar May 14 '20 15:05 lthibault