Also, you should technically be doing `#if target.threaded` and not `#if sys`. `sys` does not always imply thread support.

oh, didnt know that, nice one

i guess nodejs being a good example?

Also Lua and PHP.

Math.random isnt random when in threads, guess id need to change the seed somehow?

doesnt matter so much, was just trying to introduce some random delays to make sure things were working as expected

Which target?

hxcpp

0.744174013147131 every time (well, not every run, every thread of each run)

totally different (random) numbers before i kick off the thread

in fact, actually, `0.744174013147131` each run

... ... weird

nice its working though... 😌

yeah, or hxcpp calling the function weirdly...

anyways, not an issue - just wanted random to add fake delays to make sure things were queuing as i expected them to...

generating the number outside of the thread works fine... throw away code

Hxcpp just uses the libc rand function: <https://github.com/HaxeFoundation/hxcpp/blob/791149398bf0f47f274aaf409a797ad5f8738e21/src/hx/StdLibs.cpp#L221-L229> But, looking at a stackoverflow answer, it seems that rand is not MT-safe (at least it wasn't in the past on Linux, and might not be on windows)

yeah, i dont think its thread safe on windows

> The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call. This might just be the seed value to be used by the next call, or it might be something more elaborate. In order to get reproducible behaviour in a threaded application, this state must be made explicit. The function rand_r() is supplied with a pointer to an unsigned int, to be used as state. This is a very small amount of state, so this function will be a weak pseudo-random generator. Try drand48_r(3) instead.

Note that those are the Linux/glibc docs, and that the up-to-date version of those says that rand is thread-safe.

fair enough, something "interesting" to keep in mind

Ah, I think the problem might be that the seed is thread local, but hxcpp only calls `srand` on the main thread. So on other threads it'll use some default seed and thus always yield the same values. (Assuming that MSVC's impl is similar to Wine's: <https://github.com/wine-mirror/wine/blob/e658a30a917b0403a1e8f7ed86a8fc0138d990a8/dlls/msvcrt/misc.c#L55-L63>)

makes sense, and defo 100% what im seeing

im might ask you to sanity check my reworked http thread code if you have 5 mins - its not ready yet (cleaning up) - oh and i also _do_ need to shadow haxe.Timer in haxeui-hxwidgets (probably should have done that yonks ago)

I would advise against shadowing haxe.Timer if possible, a better solution is to wire up the event loop.

any docs / pointers on how to do that? I might just shadow for now and make a note to wire it up once i know how that would work in wx

<https://github.com/Apprentice-Alchemist/Arcane/blob/dev/src/arcane/Lib.hx#L63-L75>

so just call mainLoop.tick() basically?

and progress()?