On 07/03/15 19:38, Emil Velikov wrote:
On 07/03/15 07:23, Jose Fonseca wrote:
...
we still
didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
tree gave me pause.
The only way I can think about resolving this, is to use call_once() to
initialize the mutex,
Yes, I'm afraid so.
Static initialization of is much simpler than the call_once paradigm,
but unfortunately ISO didn't standardize a static initializer for ISO
C11 threads.h, and we can't tell whether it will be possible to somehow
to provide _MTX_INITIALIZER_NP on top of future C11 threads.h
implementations that we might care about.
In particular, it is possible that GLIBC's C11 threads.h implementation
of mutex will not be just a wrapper around pthreads:
https://sourceware.org/ml/libc-alpha/2014-02/msg00782.html
https://sourceware.org/bugzilla/show_bug.cgi?id=14092
And if mutexes become opaque binary structures, then it will really be
impossible.
Maybe that's why ISO didn't do it -- precisely so that C11 mutexes
internal representation doesn't need to be part of the ABI, only its
size is, and standard lib is free to change its internals, withing that
size.
but I'm not 100% sure if T2 will sync until T1
call_once's func has returned. How does it sound ?
I believe those are precisely the semantics of call_once.
...
We can can consider move the c99_foo.h/c11_foo.h them somewhere else
(another subdirectory, or util) or renaming them (like u_foo.h).
I have no objection on moving the file, but please keep the file name in
some form that makes it obvious about the spec compat/wrapping it provides.
FYI I'm contemplating on about adding a final wrapper - c99_string.h. It
should nuke nearly all of the remaining compiler abstraction that we
have around - mapi, egl, gallium, mesa, glsl...
-Emil
Sounds good to me. I can build-test them if Brian's not available.
I wonder if we should remove src/gallium/auxiliary/util/u_snprintf.c too.
This implementation of snprintf was necessary when we needed to build
gallium for XP kernel mode, which didn't support floating-point support,
but nowadays MSVC's _snprintf suits just as well AFAICT.
On the other hand, we should be careful about localization, as using the
system's snprintf might easily cause floating/integers to formatted
weirdly (extra spaces, commas, or different decimal separators. etc), so
it's not safe to use it for things beyond user messages/logs...
That is, it might be better to override
#define snprintf _unlocalized_snprintf
#define asprintf _unlocalized_asprintf
[...]
and provide our own implementations of all these...
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
