[PATCH] include: Use fixed stack size for rbtree.

Henri Verbeet hverbeet at gmail.com
Mon Mar 21 06:38:00 CDT 2016


On 21 March 2016 at 11:25, Alexandre Julliard <julliard at winehq.org> wrote:
> Henri Verbeet <hverbeet at gmail.com> writes:
>
>> On 21 March 2016 at 04:50, Alexandre Julliard <julliard at winehq.org> wrote:
>>> While we probably don't want that in all cases, having the option of a
>>> simpler, allocation-free rbtree would be nice. I suspect there are a
>>> number of global lists that could benefit from that.
>>>
>> I don't know. I think that outside of D3D it's only used in dbghelp
>> and winemenubuilder, and at least in the winemenubuilder case it might
>> be better to just sort the prog ID list before using it to generate
>> associations. As for the usage in D3D, I think there could potentially
>> be value in having a stack per-thread instead of per-rbtree, but I
>> don't think that would necessarily make things simpler. Having a fixed
>> stack size could certainly be done, but I don't think simply
>> increasing the size of struct wine_rb_tree would make things better
>> for any of the existing cases.
>
> Sure, for the existing cases it's fine. My feeling is that there may be
> more use cases if it was more straightforward to use. I know that a
> couple of times I considered using an rbtree but didn't, because I felt
> the potential gain wasn't worth the complexity (not only the extra
> functions, but also the need to add error handling for allocation
> failures).
>
Allocating the maximum stack size on initialisation in exchange for
never having allocation failures could be worth it, yeah. Note that
wine_rb_put() can also fail when trying to insert duplicate values
though. I suppose we could change that to either replace the existing
entry or to fail silently.



More information about the wine-devel mailing list