Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a method to get a summary of available backends #180

Open
grlee77 opened this issue Jul 12, 2019 · 9 comments
Open

add a method to get a summary of available backends #180

grlee77 opened this issue Jul 12, 2019 · 9 comments

Comments

@grlee77
Copy link

grlee77 commented Jul 12, 2019

from the discussion in scipy/scipy#10383

should uarray have some sort of function to report what backends are currently global and/or registered?

@hameerabbasi
Copy link
Collaborator

@grlee77 Would you prefer this in the first version?

@grlee77
Copy link
Author

grlee77 commented Jul 15, 2019

I don't think it is critical, just something to consider potentially adding at some point.

@hameerabbasi
Copy link
Collaborator

cc @peterbell10 This is important for dask.distributed, not just getting, but setting global backend state.

I was thinking of the following approach:

  • Transform the set of backends into an iterator of an internal type.
  • Return the iterator of the type wrapped in Python when asked
  • Provide a way to set the global state.

@peterbell10
Copy link
Contributor

Can you explain what's different about dask.distributed?

@hameerabbasi
Copy link
Collaborator

hameerabbasi commented Jul 29, 2019

The Python process is separate, possibly even on a different machine, but the context needs to be synchronized or passed to the child process.

@peterbell10
Copy link
Contributor

So the whole of uarray's state needs to be persisted into another process. In that case it would probably be easiest to just return something like a dictionary of lists, otherwise the pickling would have to be handled manually.

@hameerabbasi
Copy link
Collaborator

That would be good, yes. 😄 I'm wonder if there's a way to do this with multiprocessing that doesn't involve modifying end-user code.

@hameerabbasi
Copy link
Collaborator

Internally, we should keep C++ native objects, so as not to degrade performance.

@hameerabbasi
Copy link
Collaborator

Is this resolved by #244 and #220? Or would such a list still be preferred?

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

No branches or pull requests

3 participants