On 10/25/2012 11:17 AM, Eric Anholt wrote:
Ian Romanick <i...@freedesktop.org> writes:
From: Ian Romanick <ian.d.roman...@intel.com>
This should fix some problems related to compiling shaders in different
contextes from multiple threads.
This is pretty nasty. I think de-rallocing this file might end up nicer
(we'd need a destructor that frees type->name and type->fields.whatever,
and a hash walk that calls it in _mesa_glsl_release_types and frees the
key string), then mutexes would only be needed for the structure/array
hash table inserts with no recursion issues.
Does that sound reasonable?
Yeah...the random booleans everywhere is pretty nasty. This is usually
the sort of thing you do as a last resort...let's try something else first.
Eric's suggestion of de-rallocing makes sense to me. Making the fields
allocated normally (new/delete/delete[] via ctors/dtors) is
straightforward and removes the contention on mem_ctx.
The top-level allocation of glsl_type objects appears to be done without
ralloc already, which surprised me.
At that point, you should really only have to lock the hash table
insertions in get_array_instance() and get_record_instance(), which
seems quite reasonable.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
