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

async + threads:on + globals = error #5738

Closed
yglukhov opened this issue Apr 20, 2017 · 7 comments
Closed

async + threads:on + globals = error #5738

yglukhov opened this issue Apr 20, 2017 · 7 comments
Labels
Async Everything related to Nim's async

Comments

@yglukhov
Copy link
Member

import asyncdispatch
var s = "hi"
proc foo() {.async.} = echo s
nim c --threads:on test.nim
test.nim(3, 12) template/generic instantiation from here
Projects/nim/lib/pure/asyncmacro.nim(31, 8) Error: 'cb' is not GC-safe as it accesses 'nameIterVar' which is a global using GC'ed memory

Originated from dom96/jester#110

@Araq
Copy link
Member

Araq commented Apr 20, 2017

That works as expected. You cannot use global GC'ed memory with --threads:on.

@zielmicha
Copy link
Contributor

Shouldn't this only apply to gcsafe procs?

We call a proc p GC safe when it doesn't access any global variable that contains GC'ed memory (string, seq, ref or a closure) either directly or indirectly through a call to a GC unsafe proc.

@yglukhov
Copy link
Member Author

@Araq, are you saying that the following code should not compile with --threads:on?

var s = "hi"
proc foo() = echo s

Because now it compiles just fine ;)

@Araq
Copy link
Member

Araq commented Apr 21, 2017

No, I'm saying what the manual says and you ignore what the .async transformation does.

@yglukhov
Copy link
Member Author

Well I know that async puts gcsafe everywhere. But what's the reason for that? As far as I understand async procs are perfectly safe to use globals in a single thread.

@andreaferretti andreaferretti added the Async Everything related to Nim's async label Jun 21, 2017
@andreaferretti
Copy link
Collaborator

@dom96 Do you have an idea why gcsafe is used in async?

@yglukhov
Copy link
Member Author

yglukhov commented Jul 6, 2017

Future defines it's callback as gcsafe, because one might want to make a gcsafe async proc. So every callback we store in the future should be gcsafe. I wonder if we can somehow allow both gcsafe and gcunsafe code in futures...

yglukhov added a commit to yglukhov/Nim that referenced this issue Jul 6, 2017
yglukhov added a commit to yglukhov/Nim that referenced this issue Jul 6, 2017
yglukhov added a commit to yglukhov/Nim that referenced this issue Jul 6, 2017
yglukhov added a commit to yglukhov/Nim that referenced this issue Jul 14, 2017
@Araq Araq closed this as completed in bdf6f59 Jul 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Async Everything related to Nim's async
Projects
None yet
Development

No branches or pull requests

4 participants