Wrapping CivetWeb in haxe, hx::GCEnterBlocking()

1

CivetWeb will spawn and reuse threads to handle requests.
Civetweb is calling my callback in every new thread so I could set it up (register in GC).
On every request, civetweb will call my haxe function (in the worker thread), my haxe function will wait on a lock, pass the lock to MainLoop who has ownership on some internal data, delegate some work to other threadpools, and release the lock on finish. so civetweb will receive the response test, free the memory and mark the thread for reuse.

Some times my application locks up, when I pause it it seems like he last instruction was in futex wait, and the call stack is related to GC, I suspect that I need to use gc_enter_blocking.

When I tried to use it from cpp.vm.Gc.enterGCFreeZone(), I did recive zone mismatch.

I want to do it from cpp using hx::GCEnterBlocking(), where is the defenition of it, which header to need to include in order to use it from CivetWeb code?

Please forgive for using a single thread to process all my requests, I am still cleaning up my logic to make it thread safe, but I suspect that the lockup is GC related, and not related to my code, e.g. it always locks at random lines, not before a lock, or some IO.

Also please advice of any tools that could be used to identify the locking stacks.

After some loggin I was able to identify that new threads are getting stuck right after callling SetTopOfStack

cout << "new thread type " << thread_type << endl;//log is visible even when application stops handling requests.
        if (thread_type == 1)
        {
            int inTop = 0;
            hx::SetTopOfStack((int *)&inTop, true);
        }
        cout << "done initing thread" <<endl;//log not logged
1 Like
2

Hi

I changed the logic a ittle but still having the same issue.

I am not registering the civetweb threads in haxe, and they are not calling into haxe.
I have a single worker thread, that is registered with haxe, but this thread never blocks until haxe has the response.
The requests are stored in a map<uint,promise> so the civetweb thread can wait for them.
The worker thread reads from a channel the request information, along with an ID
Haxe will call back into cpp when the response is done, with an ID, the correct promise could be looked up, and free the civet thread.

But it is still getting stuck after a few thousand requests,

Here is the projet

1 Like
3

Please take a look at the docs Threads And Stacks - Haxe - The Cross-platform Toolkit
May be it will help you:)

4

Hi

Thanks for the correct answer that I wish would be so correct, It is always the best to follow the source.
However before posting I’ve tried to follow it to the best of my understanding, I might be dumb sometimes and miss an important detail, I wish I could know what I’ve missed

BTW the mention of hx::GCEnterBlocking() in the official documentation is probably flawed, there is no such function, instead I found GCEnterGCFreeZone, similer to the c/haxe name, hard to assume that the documentation errnously changed a term, but the cpp function doesn’t exist in the sources.