Potential bug: get_thread_id / rpmalloc_heap_thread_set_current about rpmalloc HOT 10 CLOSED

I used to run my own small company called "Rampant Pixels" - but it doesn't exist anymore, so these days it could mean anything :)

from rpmalloc.

I would assume not many people have tried using it on a platform that falls back to that get_thread_id implementation. I'll see if I can sort out the implementation to do the right thing in this fallback case.

I would suggest you implement a correct get_thread_id in your port though, this fallback was never indented for actual use :)

from rpmalloc.

I would suggest you implement a correct get_thread_id in your port though, this fallback was never indented for actual use :)

Yeah, was an easy fix as there's a built-in u64 thread_index I could use.

from rpmalloc.

OT, but I don't want to make an issue because it's probably not a bug: why is this line a naked assert rather than rpmalloc_assert?

https://github.com/mjansson/rpmalloc/blob/develop/rpmalloc/rpmalloc.c#L1546

from rpmalloc.

I guess I simply forgot to update that line when introducing the error callback and custom assert macro :)

from rpmalloc.

Fixed now

from rpmalloc.

I decided to simply error out in compilation when there's no implementation for get_thread_id as there are assumptions in the implementation that the thread ID is static for the lifetime of the thread.

from rpmalloc.

Seems like the best solution. Can I ask on my way out the door: what does the rp_ stand for?

from rpmalloc.

Hey, spotted another thing that looks weird, but not sure is really a bug (so just posting here instead of raising):

atomic_incr returns the new value, so is the 1 + ... needed?

from rpmalloc.

No, it is not needed - I think it's a left over from the initial iterations where the atomic wrappers had the same semantics as atomic_fetch_add and returned the original value instead of matching InterlockedIncrement semantics returning the incremented value.

It's not really a bug, it only affects the starting heap ID value which will be set to 2 instead of 1 - the important bit is that it's non-zero.

from rpmalloc.