| > But this isn't state of the process image that needs to be serialised, it's state of the connection between two hosts and some kernel configuration on those hosts. Programming language doesn't play into it at all. It is because UNIX is written in the C language that there are even multiple flat address spaces instead of segments or a single address space systemwide. The fact that the kernel exists at all is also due to this. It has everything to do with the implementation language. > Languages "such as Lisp" will have the exact same problem, for the same reason. Under UNIX, yes. > Collecting all of the "components" of the connection and sending them to a different host won't make the other host start sending packets to the new recipient, or replay the in-flight packets (which is state on intermediate routers, different computers than the connected ones entirely), or fix the ARP tables on the neighbouring hosts. None of that is available, and certainly isn't writeable, to the host doing the serialising. It may very well require some specialized machinery, but not nearly so much as one may think to be necessary. > To play some silly semantics games, this isn't so much about _serialising_ a connection as it is about _deserialising_ the connection and having it work afterwards. That's implicit. I needn't write of deserializing when writing of serializing, as one is worthless without the other, at least in most cases. > That act has literally nothing to do with programming language. Look at what Lisp and Smalltalk systems could do before UNIX existed and tell me that again. |
That is flat out wrong. C supports multi-programming in a system that has one address space (that includes the kernel too). Programs just have to be compiled relocatable.
You know, like what happens with shared libraries: which are written in C, and get loaded at different addresses in the same space, yet access their own functions and variables just fine.