4 ms·
> compared to Python or Ruby, where because of the GIL you _must_ place an apache/nginx/haproxy in front of it and also run a bunch of unicorns or something sim
by blibble 10y ago
> compared to Python or Ruby, where because of the GIL you _must_ place an apache/nginx/haproxy in front of it and also run a bunch of unicorns or something similar on different ports
or you know, just call fork() a few times, like Apache has done for more than a decade
- mentat 10y agoAnd hope you don't have any state that can collide.
- jldugger 10y agofork() starts new processes, so that would be a weird state to collide.
- mohaine 10y agoI think you mean that if you are calling fork you better not have any state. Otherwise you will soon have multiple independent/mutated copies of your state which is normally not a good thing. But you are correct that they would not collide.
- jldugger 10y agofork() starts new processes, so that would be a weird state to collide.
- drvdevd 10y agoIsnt that a lot more overhead than green threads in a single proc?
- KirinDave 10y agoIt doesn't matter if you have work outside of I/O to do for request responses.
- KirinDave 10y agoThis is precisely what unicorn is meant to do though, it's just a trope of the architecture to use hproxy on top. Calling fork() internally is ultimately akin to what everyone is going to do. Why not use a library to do this and let that code gradually get tempered to a reliable status?