> for 1) if you can put your sockets 'close on exec' no?
Yes, if you're the one that opened the socket. If you're using a library that opens that socket for you (e.g. a memcached or postgres library in my example), you don't necessarily have access to the socket itself. And now instead of children corrupting the parent's socket, you just have children with closed sockets. So you still have to solve the inherited-resource-sharing problem, FD_CLOEXEC isn't magic fairy dust.
> 2) how about using shared memory?
Possible but has its own downsides (you can't lock with regular posix mutexes, you have to make sure that the memory you're sharing is all in the shared block so you can't just use malloc, which means that you can't share objects that you don't control the allocation of, like, say, libraries' objects).
Yes, these are solveable problems. There are lots of other ones, these are just easy examples. Like I said:
> Yeah, you can design around it. But with threads, you don't have to.
Yes, but:
> for 1) if you can put your sockets 'close on exec' no?
Yes, if you're the one that opened the socket. If you're using a library that opens that socket for you (e.g. a memcached or postgres library in my example), you don't necessarily have access to the socket itself. And now instead of children corrupting the parent's socket, you just have children with closed sockets. So you still have to solve the inherited-resource-sharing problem, FD_CLOEXEC isn't magic fairy dust.
> 2) how about using shared memory?
Possible but has its own downsides (you can't lock with regular posix mutexes, you have to make sure that the memory you're sharing is all in the shared block so you can't just use malloc, which means that you can't share objects that you don't control the allocation of, like, say, libraries' objects).
Yes, these are solveable problems. There are lots of other ones, these are just easy examples. Like I said:
> Yeah, you can design around it. But with threads, you don't have to.