Mirror of forum.nim-lang.org

5635 :: {.gcsafe.}, What does {.threadvar.} do to make a function gcsafe?

• mp035 (orginal) [2019-12-04T08:52:06+01:00] view original

  Hi, I'm working with asynchttpserver and I found that I can not access global variables from within the server callback.

  This seems to be because the server requires a {.gcsafe.} callback, and if a global variable (in this case a table) is accessed from within the callback it is no longer gc safe.

  Adding the {.threadvar.} pragma to the global variable fixed the error, but I don't know why. So:

  1. How does accessing global variables make a function not gcsafe?
  2. What does the threadvar pragma do to fix this?

  Thanks.

---

• kidandcat (orginal) [2019-12-04T10:07:09+01:00] view original

  The Threadvar pragma, as its name explains, marks the variable as a thread variable, then each thread you create will have its own copy of that variable, thus, even if you error has dissapeared, you will find that if you modify that variable in your thread A, and you then read it in your thread B, you will find that it will be empty in B because A has written in its own copy, not in B's copy of the variable.

---

• mp035 (orginal) [2019-12-04T10:57:14+01:00] view original

  Thank you, that explanation makes sense regarding {.threadvar.} however I am now confused as to why I need to worry about it at all. I am using async http server which I am assuming is concurrent (single threaded), so everything should be running in the same thread. This would explain why the threadvar state is consistent across my application, but does not explain why I need to worry about threadvars. Do you know why threadvar is even required?

---

• mratsim (orginal) [2019-12-05T02:32:47+01:00] view original

  Iirc the gcsafe requirement was made so that it would not be breaking in the future to make async threadsafe.

---

• mp035 (orginal) [2019-12-06T01:00:58+01:00] view original

  Thank you @mratsim. I did a lot of research and found an old github issue discussing implementing threads in asynchttpserver. Araq closed it without action noting that httpbeast is available, which is esentially a multithreaded server. Do you think I should file an issue requesting the removal of .gcsafe seeing as there are now no plans to thread the server? It would remove this kludge of adding threadvars to the application.

---

• mratsim (orginal) [2019-12-06T12:24:10+01:00] view original

  Sure, it's better to have a discussion. But I think the constraints are not on the asynchttpserver module but directly on asyncdispatch, I may be wrong though

---

• rayman22201 (orginal) [2019-12-07T02:45:33+01:00] view original

  As you noted, the stdlib asynchttpserver is not multi-threaded, but httpbeast is multithreaded.

  But, both libraries use the same core stdlib asyncdispatch (they were written by the same author @dom96).

  asyncdispatch supports both single threaded and multi-threaded environments. This is why the {.gcsafe.} is required.

---

• kidandcat (orginal) [2019-12-07T17:51:27+01:00] view original

  Anyway you stated you got an error accesing the global variable, if you don't compile your program with --threads:on you will get only a warning and it will compile correctly

---

• mp035 (orginal) [2019-12-09T01:53:29+01:00] view original

  @kidandcat Yeah, you are right, it's not an error, just a warning, sorry. I'm used to C where a warning usually means I've done something wrong. @mratsim and @rayman22201 thanks for explaining that, it seems like the issue has been thought through, so there's no point raising it.

---