On Fri, 6 Nov 2015, Piotr Caban wrote:
On 11/06/15 11:28, Martin Storsjo wrote:
int CDECL _callnewh(MSVCRT_size_t size) {
- int ret = 0;
- LOCK_HEAP; if(MSVCRT_new_handler)
- (*MSVCRT_new_handler)(size);
- return 0;
- ret = (*MSVCRT_new_handler)(size);
- UNLOCK_HEAP;
- return ret; }
It doesn't make sense to lock heap cs in this case. Native is not doing it (at least in case of msvcp90.dll).
Hmm, but wouldn't it risk a race with another thread doing set_new_handler then? OTOH I guess that's ok/expected?
But there's a similar lock in MSVCRT_operator_new; should we do the same locking on the msvcp side instead then, or just skip it altogether?
The return value change looks almost correct - the function only returns 0 or 1.
Ok, so should I force the return value to 0 or 1 regardless of what the function returns? I.e. ret = (*MSVCRT_new_handler)(size) ? 1 : 0;
(or !!), or should I just repost it without the locking?
// Martin