Re: [AD] Allegro 4.2 planning |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Evert Glebbeek wrote:
I agree, making Allegro 64 bit clean should be done as soon as
possible.
Should we use C99 int32/int64 etc. types to do this? I'm not sure we
want to switch the 4.2 branch to C99 at this point... I don't know of
any other way to get an integer of a specific size though.
But please don't break Allegro for C++ users. AFAIK these new types are
not supported by C++ compilers.
About thread-safety - I think e.g. the X11 bitmap access is quite
safe now. I can successfully draw from different threads (well,
Allegro timer thread) to the screen after Chris' last patch.
Yes, that's also the impression I get. It even seems to run fine on a
dual processor machine, which I think is about the strongest test
you can do for something like this.
Another test for thread safety can be valgrind (with helgrind tool). It
can detect variables that are accessed from several threads without
proper synchronization.
By the way, can `allegro-config --libs` return also '-pthread' as well?
I encountered some weird problems trying to run allegro based game in
valgrind when -pthread was not specified in the linker command line.
Valgrind just ignored all mutexes and the program died horribly.
Also, are all these segment prefixes in assembly code really needed?
Valgrind does not like them very much and allegro should be configured
with --disable-asm if you want to use valgrind with it.