Hacker News new | past | comments | ask | show | jobs | submit login

Okay but then you're talking about designing a completely new kind of kernel which has a completely different concept of what a "process" is, which is quite far away from "we should've just used SmallTalk".

Besides, no matter how you design the system, there will be a categorical difference between communication which is expected to be fallible and communication which is expected to be infallible. The "communication" between a caller and a callee is expected to be infallible, for example. Communication between threads in a process (in the UNIX and Windows model) is expected to be infallible.

Communication between an app and a system service is expected to be fallible; at the very least, the system service has to expect that the app might misbehave in any number of ways, even if you argue that the app should expect the system service to be perfect.




Depends pretty much how those threads were started.

In Windows there are fun things like COM apartments, owner module scopes, local RPC, wrapping in-proc COM into DCOM remoting.

Apple and Google have similar local RPC features coupled with multithtreading.


I don't understand what you think depends on how threads were started.


An HN comment is not big enough to explain OS specific threading models across component systems, and dynamic libraries.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: