dom96 / httpbeast

A highly performant, multi-threaded HTTP 1.1 server written in Nim.
MIT License
450 stars 53 forks source link

use joinThreads avoiding #80 #88

Closed bung87 closed 1 year ago

bung87 commented 1 year ago

fix #80

I run helloworld.nim on windows WSL2, start and restart manully, randomly crash by SIGSEGV, even I remove settings param entirely from eventLoop, valgrind tells possibly lost in 3 blocks, and point out proc threadProcWrapDispatch[TArg] , however I don't see any problem there, maybe someone can tell me how this PR works. I just follow the theory "create threads" -> "join threads" like in other language.

ThomasTJdev commented 1 year ago

Nice! I have tested the the PR with a minimal code sample, and it solves the segfault in https://github.com/nim-lang/Nim/issues/21422. I will test it on a larger code base tomorrow.

This PR is actually a revert of the PR #62 where the main thread was included as one of the worker threads. I'm not aware whether this could block other code started on the main thread.

dom96 commented 1 year ago

I believe @ajusa fixed some real problems with #62, maybe they can remind us of the context.

But in general, I think the underlying compiler issue should be fixed instead. The fact this change works is likely just luck.

ajusa commented 1 year ago

It's been two years so my memory is a little fuzzy. I definitely recall that this was a performance improvement, as before httpbeast would spawn num of CPU + 1 thread for joining all of them, and with the change it now uses the main thread to serve requests. This led to less contention/overhead IIRC.

Based on the PR description there might have been a different issue that was fixed as well, which was calling async code before the server started? Like if you issued an async request right before the server was started, it wouldn't be polled because eventLoop wasn't called in the main thread. I don't recall the specifics anymore, but I want to say that was the actual issue that was solved.

I'm not sure why a segfault is occurring as a result of my changes - it's possible that all we need is a join thread after the main thread runs the event loop, to ensure everything is cleaned up correctly?

bung87 commented 1 year ago

if you want runs async you may try https://github.com/ringabout/httpx/pull/27, note your main thread eventloop still block the thread. the facts are :

  1. there's destroyThread proc in nim under when false block https://github.com/nim-lang/Nim/blob/281016a8022b8e8308e3e578b2c2daa6df4a66a1/lib/std/typedthreads.nim#L153
  2. there's proc close in httpbeast under when false block which not implemented yet.
  3. orc have some issues not solved yet
  4. httpbeast run is not asynchronous procedure
  5. start and restart randomly crash on linux, therefore httpbeast mainly target to unlix like platform.

am not using httpbeast myself, just trying to help someone's problem, so I'll leave this.

bung87 commented 1 year ago

explanation by AI:

When a thread is created, it has a default state of being a joinable thread, which means that calling the join method on it will wait for the thread to finish before allowing the program to exit. If you do not call join and the thread is still running when the main thread exits, it will be terminated abruptly and any resources it was using might not be properly released.