Does anyone know what the 2nd "processes" is referring to, in the 2nd paragraph here?
---------------------------
In a sane world, specification 30 words long, like the one above, would be implementable in 100 lines of C code. If it requires several thousand lines of code, there's clearly something broken with our programming model.
As I've argued in part I of this essay, to get a simple programming model you have to spawn a thread per TCP connection. But given that threads are expensive (and processes even more so) and that sharing state between threads is insane, bordering on suicidal, what you need are lightweight green threads and a simple communication mechanism to send messages between them. In UNIX of old they were called processes and pipes. In Go they are called goroutines and channels. In Erlang they are known as processes and mailboxes.
-----------------------------
I understand this:
"But given that threads are expensive (and processes even more so)"
but I am confused by this 2nd use of "processes":
"In UNIX of old they were called processes"
Was there an old version of UNIX that had lightweight threads? What were they? How were they implemented? How were they different from the processes we have now?
When I think of processes on Unix I think "threads are expensive (and processes even more so)". Was this different at some point in the past?
As to implementing new communication protocols, none of us should underestimate the complexities. Jon Postel was not stupid, but even he made mistakes. Recall that by 1973 they felt they had TCP 3 in a mostly final form, but then in August of 1977 Postel said they had made a terrible mistake by lumping too much together in TCP. He then spent a year pulling TCP and IP apart into the 2 separate protocols that we have now.
That example is well known, but if you read through the old RFCs, you realize there are some ideas that were explored and then abandoned. Among the really wild ideas:
"we are contemplating allowing sender and receiver to specify different byte sizes and consider bits as the basic unit "
This is from:
https://tools.ietf.org/html/rfc128
And if you try to create your own communication protocol, you will also go through a similar period of trial and error.
---------------------------
In a sane world, specification 30 words long, like the one above, would be implementable in 100 lines of C code. If it requires several thousand lines of code, there's clearly something broken with our programming model.
As I've argued in part I of this essay, to get a simple programming model you have to spawn a thread per TCP connection. But given that threads are expensive (and processes even more so) and that sharing state between threads is insane, bordering on suicidal, what you need are lightweight green threads and a simple communication mechanism to send messages between them. In UNIX of old they were called processes and pipes. In Go they are called goroutines and channels. In Erlang they are known as processes and mailboxes.
-----------------------------
I understand this:
"But given that threads are expensive (and processes even more so)"
but I am confused by this 2nd use of "processes":
"In UNIX of old they were called processes"
Was there an old version of UNIX that had lightweight threads? What were they? How were they implemented? How were they different from the processes we have now?
When I think of processes on Unix I think "threads are expensive (and processes even more so)". Was this different at some point in the past?
As to implementing new communication protocols, none of us should underestimate the complexities. Jon Postel was not stupid, but even he made mistakes. Recall that by 1973 they felt they had TCP 3 in a mostly final form, but then in August of 1977 Postel said they had made a terrible mistake by lumping too much together in TCP. He then spent a year pulling TCP and IP apart into the 2 separate protocols that we have now.
That example is well known, but if you read through the old RFCs, you realize there are some ideas that were explored and then abandoned. Among the really wild ideas:
"we are contemplating allowing sender and receiver to specify different byte sizes and consider bits as the basic unit "
This is from:
https://tools.ietf.org/html/rfc128
And if you try to create your own communication protocol, you will also go through a similar period of trial and error.