search

ufairiya / mongoose

Automatically exported from code.google.com/p/mongoose
MIT License
0 stars 0 forks source link

Enhancement: Threading Model #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
IMHO the simple threading model used by Mongoose is not great for 
performance.  Better would be to keep spawned threads around after 
connection closure waiting for another connection, exiting only after some 
configurable idle time.

Another requirement for this, which I believe should be implemented anyway, 
is not to detach threads but keep track of them and properly "pthread_join" 
each of them at the time of mg_stop.  This would prevent long-running 
requests from accessing context-level data that has been freed by the main 
thread.

Original issue reported on code.google.com by caleb.ep...@gmail.com on 5 Mar 2009 at 8:27

GoogleCodeExporter commented 9 years ago

Original comment by valenok on 5 Mar 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
Part 1 is implemented (to be ported on Windows still)
Part 2 (pthread join) is started.

Original comment by valenok on 23 Mar 2009 at 7:12

GoogleCodeExporter commented 9 years ago 
Very nice!  Thank you.

Original comment by caleb.ep...@gmail.com on 24 Mar 2009 at 2:51

GoogleCodeExporter commented 9 years ago 
Completed part (2).
Now, windows port left.

Original comment by valenok on 24 Mar 2009 at 3:50

GoogleCodeExporter commented 9 years ago 
This almost does it.  mg_stop doesn't do anything to wait for the 
listening_loop to 
complete.  I'd suggest waiting for that thread and only then calling mg_fini 
from the 
thread that called mg_stop.

Original comment by caleb.ep...@gmail.com on 24 Mar 2009 at 4:12

GoogleCodeExporter commented 9 years ago 
The way it works now is that mg_stop() only sets a flag and returns. Master 
thread
exits its loop, and calls mg_fini(), which waits until all threads finish. I 
don't
think that mg_stop() should block, since waiting could be long.

Original comment by valenok on 24 Mar 2009 at 4:18

GoogleCodeExporter commented 9 years ago 
Perhaps an mg_wait() function that does both then?  When I'm embedding my own 
code 
into mongoose, I need to know the server has fully stopped before I can safely 
release my own resources...

Original comment by caleb.ep...@gmail.com on 24 Mar 2009 at 5:03

GoogleCodeExporter commented 9 years ago 
Maybe a boolean flag to mg_stop() is sufficient, "to wait or not to wait" (c) ?

Original comment by valenok on 24 Mar 2009 at 5:41

GoogleCodeExporter commented 9 years ago 
Perfect.

Original comment by caleb.ep...@gmail.com on 24 Mar 2009 at 5:42

GoogleCodeExporter commented 9 years ago 
After some thinking and experimenting, I decided to leave the API unchanged.
mg_stop() now blocks unconditionally until all Mongoose threads exit.

Original comment by valenok on 25 Mar 2009 at 11:34

GoogleCodeExporter commented 9 years ago 
Windows port completed.
Closing this issue.

Original comment by valenok on 25 Mar 2009 at 8:40

GoogleCodeExporter commented 9 years ago 
In the latest mongoose, the "pool of threads" behavior seems to have gone away 
and I 
get a new thread to handle every request.  Is this intentional?

Original comment by caleb.ep...@gmail.com on 19 Jun 2009 at 5:33

GoogleCodeExporter commented 9 years ago 
No, this was a breakage.
SVN head has thread pool functionality fixed. You can either update to head, or 
wait 
until 2.7 which will be released soon.

Original comment by valenok on 5 Jul 2009 at 7:50