This is the mail archive of the pthreads-win32@sourceware.org mailing list for the pthreas-win32 project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello Ross,I wasn't aware of that function, or had forgotten that it exits. I don't do a lot of C programming.
Ross Johnson wrote:Hi Ramiro,
I agree that requiring the attach/detach routines is clunky, however...see my comments inline.
Ramiro Polla wrote:pthreads-win32 requires programs that use the library statically to call some (de)initialization code, which would be the same code called by DllMain(). There are plenty of messages regarding this on the mailinglist.It could be done this way for initialisation, but you'd still need to run the process detach routine explicitly before exiting
1- Why isn't this initialization done by pthreads-win32 itself? All
pthread_* functions could have an if(!initialized) {...} block before
running any code that depends on it.
Can't this be done with atexit()?
Ignore that issue, I was just brainstorming reasons to maintain the status quo.and I may have thought a long time ago that if you need one you may as well have the other, if only to make it more obvious and "in your face".
It also allows the developer to choose when initialisation occurs and, although most may not care, some might.
It could be configurable.
Yes, it's almost negligible and I use the same method to initialise static POSIX mutexes, cond vars, etc., although this one is slightly worse in that the data isn't necessarily in cache already or local. IIRC, we need to use an Interlocked routine to compare the value, not for atomicity necessarily but so that we get the memory barrier effects right. And I've found that these calls can be relatively slow due to bus locking. I'm also still assuming that every single routine needs this overhead, but that may not be necessary in the end.
For some routines, the additional overhead is not negligible, and they tend to be the most heavily used routines.
The overhead of one if()? If the branch prediction sets the if() to be unlikely, there should be 1 memory access and 1 cmp function overhead. It shouldn't even disturb the instruction pipeline.
One was the thread detach already mentioned earlier and another, a function defined as a macro, I no longer consider a problem because it need not trigger a process attach.
There are a couple of other impediments but nothing too major - they just all add up.
If you're offering to provide the patches I'll certainly try to include them. Perhaps you could also add an option to build the benchmarks in the tests folder using static linking and perhaps also compare with the dll versions.
Ideally yes, I agree, but presumably the crash occurs pretty soon in development and once fixed is fixed forever. So, in the interests of keeping overheads within the library to a minimum I think it's reasonable not to check. This is one of those APIs that absolutely needs to be as efficient as possible.2- Static pthreads-win32 libraries should at least check if they were properly initialized before allowing pthread_* functions to run. Returning an error is far better than having the program crash.
One last thing: the library was originally intended to be used only as a dll, and static linking requirements have been given only minimal attention.
Would it be ok to add another build option such as GC-static-autoinit?
Users should expect it to have a small overhead, at the price of not needing to alter their code nor the build system to work with static or shared libraries.
Oops.
Oh, and apparently you only replied to me. Could this be discussed on the mailinglist?
Regards. Ross
Ramiro Polla
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |