Skip to content
This repository has been archived by the owner on May 23, 2021. It is now read-only.

Support goroutine invocation #15

Open
lthibault opened this issue Feb 25, 2020 · 4 comments
Open

Support goroutine invocation #15

lthibault opened this issue Feb 25, 2020 · 4 comments

Comments

@lthibault
Copy link
Collaborator

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.

@spy16
Copy link
Owner

spy16 commented Feb 26, 2020

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..

@lthibault
Copy link
Collaborator Author

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.

@spy16
Copy link
Owner

spy16 commented Feb 26, 2020

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..

@lthibault
Copy link
Collaborator Author

@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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants