3 ms·
While forking is always possible, there are some things that it does solve well enough IMO. For example, sharing and reusing database connections via a connecti
by WJW 9y ago
While forking is always possible, there are some things that it does solve well enough IMO. For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Shared memory is both a curse and a blessing of course :|
- hawski 9y agoOne can always use a bit of shared memory between processes. At least it would be contained to the parts that one really want to share. There are a few ways to do that. The easiest one is mmap MAP_SHARED|MAP_ANONYMOUS.
- jsjohnst 9y ago> For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Why is this inherently easier to you with threads rather than forks? Many very successful apps use a forking model and do what you say, so I’m genuinely curious on your reasoning here.
- yellowapple 9y agoThe conventional approach would be to have a process dedicated to database communication. Other processes would then talk to that process via some IPC mechanism. This is reflected in the Erlang way of doing things (since there's no such thing as "shared memory", at least not directly); a process needing data from the DB sends a message to the DB connector process, which runs the query via one of a set of pooled connections and sends the result back as another message to the requesting process.