Hacker News Reader

Comment by Joker_vD | Hacker News Reader

And to re-iterate my point from another thread on setenv, no, "just don't call setenv() after creating threads" is not a solution because even if the code you wrote may be single-threaded, your application as a whole is not composed entirely of code written by you: the moment you link against any 3rd-party library, you program can have arbitrarily many threads before it even reaches main().

View on HN

> the moment you link against any 3rd-party library, you program can have arbitrarily many threads before it even reaches main().

what?! name one library that does this?

I think the C++ version of the zeromq library could initialize a context in a static initializer, and zmq contexts involve creating a thread.

https://zeromq.org/get-started/?language=cpp#

there's 5 listed for c++ which one creates threads before main()?

It's been a long time, so I might be wrong, but with zmqpp[1] make a global zmqpp::context and I believe it will create threads before main().

1: https://github.com/zeromq/zmqpp

Windows will have a few threads for doing IO at program startup.

I've done some work with golang. Do not know if the libraries I used were bad, but they did some nasty things before main. Some even saw it as okay to call panic

> And to re-iterate my point from another thread on setenv, no, "just don't call setenv() after creating threads" is not a solution

Yes it is.

> the moment you link against any 3rd-party library, you program can have arbitrarily many threads before it even reaches main().

So don't call setenv after you load any libraries. If that means you can't call setenv at all for your linking setup then so be it.

Reply on news.ycombinator.com