Previous | Next --- Slide 13 of 58
Back to Lecture Thumbnails
scedarbaum

As a refresher, I was reading up on why threads can bring down their entire process. The answer seems to be that, because threads share memory (their heap), if a memory exception is thrown the OS can't safely say who is affected (for instance, 1 thread could corrupt some shared memory used by every thread) [1]. However, I wonder if spawning a new process might be a bit of a heavy-handed solution. You seem to be giving up advantages you get from a shared memory space (e.g., speed, simplicity).

It therefore seems like servers could benefit from some kind of "hybrid" approach where shared memory (that is, memory that multiple threads access) could be given special protections and perhaps fail more gracefully in case of access violations. Perhaps implementing such a construct would be too complicated or, when you're done making it truly "safe", you end up with something that looks just like a process. Or maybe the complexity is not worth the potential performance gains. Any thoughts on this?

toutou

I have two questions here. First is that does each worker process have several threads to deal with different client's request? Therefore if a worker crashes, it only affect clients served by threads in this process. I‘m also confused about that, in AFS multi-thread is used instead of multi-process due to the cheaper switching cost. Shouldn't a web server has higher frequency of context switch and lower cost of recovery from failures? So why does it place less value in cost of switch?

kayvonf

@scedarbaum: Another example. If a thread segfaults, the OS kills the process. That means it would kill all threads owned by the process.

dsaksena

@toutou as for your 2nd question "Shouldn't a web server has higher frequency of context switch and lower cost of recovery from failures? So why does it place less value in cost of switch?"

When you switch between threads of a process, you don't need to remap the whole virtual memory and your TLB (a cache) doesn't get invalidated in that. Thus cost of thread switch is cheaper. Plus as @scedarbaum puts it we can write code to fail "gracefully" where maybe killing the entire process is not necessary (basically avoid fatal exceptions like Segfaults) and have low switch cost.

So we get higher frequency switch and recovery cost should also be low if we write good code helping us "fail gracefully".

rojo

@toutou: If there are several threads to cater to different client request and if one worker dies, then the thread associated with this process in in a limbo. Killing such a thread is not the right thing to do as it could be holding lock on a critical section. Killing this thread would mean other threads in the process will indefinitely wait for such a lock and this will lead to a deadlock and the entire system fails. Hence killing threads this way will not solve the problem.

gryffolyon

So the deal is in order to have protection, we take a costlier way of dealing with processes instead of a cheaper way of dealing with threads.

lament

Don't we also get security benefits from using different processes? If we are talking about hardware threads, then one thread could read the other's data - processes can avoid some of thisss

MediumPepsi

@lament I think in case of web server, this isn't about security, since the threads or processes execute server code rather than client code. One thread being able to read the others' data doesn't that one client can view other clients' data.

plymouth

@MediumPepsi While security is definitely not the primary reason processes are used instead of threads, there is still a security benefit to be had. While server code is being executed, it's still reading and acting upon client input. If the server code is buggy, exploits can be possible