3 ms·

I prefer http://silkjs.net http://silkjs.net It handles each request in a forked subprocess so it's a lot more straight forward.

by logn 12y ago

hardwaresofton 12y ago
without sounding like a web 3.0 idiot -- how do you manage to scale that? subprocesses are not cheap
- angersock 12y ago
  subprocesses are not cheap This statement depends heavily on the runtime environment. Consider either Erlang or fibers as implemented in C/C++, for example.
  - erjiang 12y ago
    We usually only refer to OS-level processes as "subprocesses". You'll see terms like "lightweight threads", "greenlets", "fibers" for concurrency units managed by the application runtime instead.
    - hardwaresofton 12y ago
      Exactly what I meant -- thanks... Are you the erjiang that wrote the blog post? If so, thanks, I thoroughly enjoyed it
- logn 12y ago
  I'm sure someone else reading can answer your question based on more experience and expertise than me... anyhow the subprocesses are re-used so there's no overhead in their creation. And if your server is doing I/O bound work (or is just waiting a lot) then it should perform ok. If everything is CPU bound, then you'd want to not create more subprocesses than cores. SilkJS lets you define the number of subprocesses you want. More info: http://silkjs.net/sync-vs-async/ http://silkjs.net/sync-vs-async/
  - hardwaresofton 12y ago
    Thanks for the additional info -- though I would argue that it starts to sound like apache+fcgi (not that it's bad), or unicorn+wsgi... I think node pushes async to an extreme that makes it truly different from what's out there. Unfortunately, it results in leaky abstractions, and lots of misguided enthusiasm as the post goes into... You could think of pure functional programming (haskell/ml) as a similar extreme -- Haskell gets a lot of concurrency/parallelism guarantees for free just because of how the language was built (pure functions,etc)... Is it wrong to think that node took a similarly crazy step, but in their case, they weren't able to rebuild the language, and that's what you get? If I wanted to event-loop, or lightweight thread stuff in python, I'd need some libraries, and many of the ones that you might find are not very easy to learn.
- general_failure 12y ago
  I don't know about silk but forking subprocess model usually involves caching the subprocess. So it's going to be as light weight as any other cgi thing.

I prefer http://silkjs.net http://silkjs.net It handles each request in a forked subprocess so it's a lot more straight forward.

by logn 12y ago

I prefer http://silkjs.net http://silkjs.net It handles each request in a forked subprocess so it's a lot more straight forward.

hardwaresofton 12y ago

without sounding like a web 3.0 idiot -- how do you manage to scale that? subprocesses are not cheap

angersock 12y ago
subprocesses are not cheap This statement depends heavily on the runtime environment. Consider either Erlang or fibers as implemented in C/C++, for example.
- erjiang 12y ago
  We usually only refer to OS-level processes as "subprocesses". You'll see terms like "lightweight threads", "greenlets", "fibers" for concurrency units managed by the application runtime instead.
  - hardwaresofton 12y ago
    Exactly what I meant -- thanks... Are you the erjiang that wrote the blog post? If so, thanks, I thoroughly enjoyed it
logn 12y ago
I'm sure someone else reading can answer your question based on more experience and expertise than me... anyhow the subprocesses are re-used so there's no overhead in their creation. And if your server is doing I/O bound work (or is just waiting a lot) then it should perform ok. If everything is CPU bound, then you'd want to not create more subprocesses than cores. SilkJS lets you define the number of subprocesses you want. More info: http://silkjs.net/sync-vs-async/ http://silkjs.net/sync-vs-async/
- hardwaresofton 12y ago
  Thanks for the additional info -- though I would argue that it starts to sound like apache+fcgi (not that it's bad), or unicorn+wsgi... I think node pushes async to an extreme that makes it truly different from what's out there. Unfortunately, it results in leaky abstractions, and lots of misguided enthusiasm as the post goes into... You could think of pure functional programming (haskell/ml) as a similar extreme -- Haskell gets a lot of concurrency/parallelism guarantees for free just because of how the language was built (pure functions,etc)... Is it wrong to think that node took a similarly crazy step, but in their case, they weren't able to rebuild the language, and that's what you get? If I wanted to event-loop, or lightweight thread stuff in python, I'd need some libraries, and many of the ones that you might find are not very easy to learn.
general_failure 12y ago
I don't know about silk but forking subprocess model usually involves caching the subprocess. So it's going to be as light weight as any other cgi thing.