Websocketd

Post by inferiorhuman » Sat, Jan 26, 2019, 9:31 AM UTC

_pmf_ wrote: post #116

jashmatthews wrote: post #71

Earlier quoted context omitted.

> processes and forking are relatively expensive This and "async is always faster" are two things which are no longer true on modern hardware. Forking a process on Linux uses the same clone() syscall as creating a thread so forking a small binary takes only tens of microseconds, leaving plenty of time for https://eli.thegreenplace.net/2018/launching-linux-threads-a...

> Forking a process on Linux uses the same clone() syscall as creating a thread The conclusion to be drawn is "Linux threads are costly", not "Linux processes are cheap".

Post by masklinn » Sat, Jan 26, 2019, 9:37 AM UTC

function_seven wrote: post #109

Matthias247 wrote: post #66

Earlier quoted context omitted.

Ah thanks that makes sense. I didn't see it when I glimpsed over the site. That should provides reliable framing on both sides. But as shown in the linked it page it also comes with the downside of not being able to send raw websocket messages which contain a new line - so it's not possible to port existing applications from other websocket servers to this one without having to change communication.

I don't understand why the daemon needs to client to escape newlines in the message. Can't it handle that before feeding the message to STDIN? For example, my browser sends: This is line one... ...and this is line two as a string ("This is line one...\n...and this is line two") and the websocketd receives that, and passes along This is line one...\\n...andthis is line two\n to the STDIN. It knows that the message is…

Post by inglor » Sat, Jan 26, 2019, 9:40 AM UTC

geocar wrote: post #115

jchw wrote: post #26

This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.

The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows

Post by arendtio » Sat, Jan 26, 2019, 9:44 AM UTC

masklinn wrote: post #120

arendtio wrote: post #112

Earlier quoted context omitted.

AFAIK, those are not 'processes' in terms of operating system processes, but instead some kind of parallel running tasks within the Erlang VM (much closer to threads). Edit: If you think I am wrong, could you please explain what is wrong?

AFAIK there is very little difference between processes and threads in linux (both are instances of task_struct), the variability in implementation details specific makes that use for classification useless, and thus the only possible separation of any use is semantics: the difference between processes and threads is whether they share internal state (generally / by default). Erlang's don't, thus processes. Go's do,…

Post by masklinn » Sat, Jan 26, 2019, 9:53 AM UTC

arendtio wrote: post #127

masklinn wrote: post #120

Earlier quoted context omitted.

AFAIK there is very little difference between processes and threads in linux (both are instances of task_struct), the variability in implementation details specific makes that use for classification useless, and thus the only possible separation of any use is semantics: the difference between processes and threads is whether they share internal state (generally / by default). Erlang's don't, thus processes. Go's do,…

Interesting. My interpretation was more along the lines of having its own process identifier (PID) and to my knowledge, OS processes have that, OS threads don't and I thought Erlangs processes don't get PIDs by the operating system either (although that might be wrong too).