I noticed that SDL is shown by the debugger to be spawning a few
threads in the beginning of SDL initialization [at least on OpenGL
context]. That’s usually not of my concern, however, I noticed that a
tool I have to use [cURL] requires for thread safety to be initialized
before any thread creation. Are those threads of any real concern in
such concepts, or they can be generally be ignored? [are they just a
way for debugger to say ‘I just used a DLL’ etc.?]
They probably mean that before any thread that will be using cURL is
spawned the “thread safety” needs to be initialised. If two or more
threads tried to initialise the “thread safety” then you could get
race conditions or resource leaks, or worse I imagine.
Any unrelated threads are probably not worth worrying about. They
certainly shouldn’t be calling cURL functions, so you should be safe.On 5 December 2010 11:43, Michael Menegakis wrote:
I noticed that SDL is shown by the debugger to be spawning a few
threads in the beginning of SDL initialization [at least on OpenGL
context]. That’s usually not of my concern, however, I noticed that a
tool I have to use [cURL] requires for thread safety to be initialized
before any thread creation. Are those threads of any real concern in
such concepts, or they can be generally be ignored? [are they just a
way for debugger to say ‘I just used a DLL’ etc.?]
They probably mean that before any thread that will be using cURL is
spawned the “thread safety” needs to be initialised. If two or more
threads tried to initialise the “thread safety” then you could get
race conditions or resource leaks, or worse I imagine.Any unrelated threads are probably not worth worrying about. They
certainly shouldn’t be calling cURL functions, so you should be safe.I noticed that SDL is shown by the debugger to be spawning a few
threads in the beginning of SDL initialization [at least on OpenGL
context]. That’s usually not of my concern, however, I noticed that a
tool I have to use [cURL] requires for thread safety to be initialized
before any thread creation. Are those threads of any real concern in
such concepts, or they can be generally be ignored? [are they just a
way for debugger to say ‘I just used a DLL’ etc.?]
They say the opposite.
“This function is not thread safe. You must not call it when any other
thread in the program (i.e. a thread sharing the same memory) is
running. This doesn’t just mean no other thread that is using libcurl.
Because curl_global_init() calls functions of other libraries that are
similarly thread unsafe, it could conflict with any other thread that
uses these other libraries.”
http://curl.haxx.se/libcurl/c/curl_global_init.htmlOn Sun, Dec 5, 2010 at 6:50 PM, Brian Barrett <brian.ripoff at gmail.com> wrote:
On 5 December 2010 11:43, Michael Menegakis <@Michael_Menegakis> wrote:
When are these extra threads created then? Is it when you call
SDL_Init(), or before?
If during SDL_Init(), can you not invoke curl_global_init() before
that? If before (at process start time), then nothing can be done, and
I assume any such threads are part of a normal process startup
I suspect they are being overly paranoid, while being strictly
correct. I cannot imagine that SDL would interfere with curl’s
initialisation routine.On 5 December 2010 17:55, Michael Menegakis wrote:
They say the opposite.
“This function is not thread safe. You must not call it when any other
thread in the program (i.e. a thread sharing the same memory) is
running. This doesn’t just mean no other thread that is using libcurl.
Because curl_global_init() calls functions of other libraries that are
similarly thread unsafe, it could conflict with any other thread that
uses these other libraries.”http://curl.haxx.se/libcurl/c/curl_global_init.html
I suspect they are being overly paranoid, while being strictly
correct. I cannot imagine that SDL would interfere with curl’s
initialisation routine.
Well, if they both use for instance inet_ntoa(), strtok() or localtime(),
just to show three standard library function whose evilness in multithread
programs is well known, they could interfere each other.
If curl documentation states a similar warning it’s obviously because it is
calling one or more of these multithread unsafe apis.
I ignore why they did not fix the problem since there is always a
thread-safe variant for those.–
Bye,
Gabry