3 ms·

Crystal is pretty neat and ticks off almost all of the boxes for me atm (For example the websockets server functionality in Kemal is super neat), but the lack o

by WJW 9y ago

Crystal is pretty neat and ticks off almost all of the boxes for me atm (For example the websockets server functionality in Kemal is super neat), but the lack of proper parallelism is kind of a killer. I know it's in the works, but afaict it has been so for almost a year now without much news...

pjmlp 9y ago
Parallelism is always possible UNIX old style, use multiple processes. It is anyway the trend we are getting back to, after we have learned our lesson how threads and plugins can bring whole processes down, while being good vehicles for security exploits.
- WJW 9y ago
  While forking is always possible, there are some things that it does solve well enough IMO. For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Shared memory is both a curse and a blessing of course :|
  - hawski 9y ago
    One can always use a bit of shared memory between processes. At least it would be contained to the parts that one really want to share. There are a few ways to do that. The easiest one is mmap MAP_SHARED|MAP_ANONYMOUS.
  - jsjohnst 9y ago
    > For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Why is this inherently easier to you with threads rather than forks? Many very successful apps use a forking model and do what you say, so I’m genuinely curious on your reasoning here.
  - yellowapple 9y ago
    The conventional approach would be to have a process dedicated to database communication. Other processes would then talk to that process via some IPC mechanism. This is reflected in the Erlang way of doing things (since there's no such thing as "shared memory", at least not directly); a process needing data from the DB sends a message to the DB connector process, which runs the query via one of a set of pooled connections and sends the result back as another message to the requesting process.
- fiedzia 9y ago
  With Rust and other languages focused on correctness, the "threads can bring whole process down" is less relevant (they still can, but it not as common as it used to be), while having one process makes a lot of things much easier.

by WJW 9y ago

pjmlp 9y ago

Parallelism is always possible UNIX old style, use multiple processes. It is anyway the trend we are getting back to, after we have learned our lesson how threads and plugins can bring whole processes down, while being good vehicles for security exploits.

WJW 9y ago
While forking is always possible, there are some things that it does solve well enough IMO. For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Shared memory is both a curse and a blessing of course :|
- hawski 9y ago
  One can always use a bit of shared memory between processes. At least it would be contained to the parts that one really want to share. There are a few ways to do that. The easiest one is mmap MAP_SHARED|MAP_ANONYMOUS.
- jsjohnst 9y ago
  > For example, sharing and reusing database connections via a connection pool is much nicer if all threads can actually access the same memory. Why is this inherently easier to you with threads rather than forks? Many very successful apps use a forking model and do what you say, so I’m genuinely curious on your reasoning here.
- yellowapple 9y ago
  The conventional approach would be to have a process dedicated to database communication. Other processes would then talk to that process via some IPC mechanism. This is reflected in the Erlang way of doing things (since there's no such thing as "shared memory", at least not directly); a process needing data from the DB sends a message to the DB connector process, which runs the query via one of a set of pooled connections and sends the result back as another message to the requesting process.
fiedzia 9y ago
With Rust and other languages focused on correctness, the "threads can bring whole process down" is less relevant (they still can, but it not as common as it used to be), while having one process makes a lot of things much easier.