Re: big responses to slow clients: Rack vs PSGI

[James Tucker <jftucker@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3906 bytes --]

On Dec 24, 2016 7:15 PM, "Eric Wong" <e@80x24.org> wrote:

Thank you for your response.

As far as departing from Rack...  I guess PSGI was one departure :)

Looking back, I think the possibility of an ecosystem of
stdlib/gems to support lightweight coroutines was lost when MRI
got 1:1 threads with YARV.  Fibers, Neverblock, Goliath never
got the critical mass to affect stdlib or most gems after that.
So yeah, I agree this really needs core/stdlib support which I
doubt can still happen.  Coro for Perl5 is in a bad, perhaps
worse spot, even.


Fibers as implemented lose their usefulness as scheduler primitives because
of their thread local overloading and strict thread binding. If that was
fixed they'd be able to be used like coroutines are used for scheduling
elsewhere.

And yet I know my brain still favors OS kernel primitives over
language-level primitives; so in that way MRI/YARV today is
closer to how my brain works w.r.t. non-blocking I/O combined
with native threads or processes as needed.  *shrug*


From a server/Io perspective this makes sense. The problem is from the
apps/users perspective. They ideally need to be able to "just write"
without managing buffers, non-blocking, multiplexing etc. That's what the
stack solutions give them that no other solution does. I do think a write
capable API is OK - that's why I introduced hijack, as imperfect as it is.
Of course hijack is hard to implement correctly in the face of 1.0 and 1.1
support, especially if you try to support pipelining. The split boolean
design was to allow cow cloneable environment objects only allocating space
for bool and some buffer pointers in the case of most requests, with the
hijack methods being localled from some preexisting server context.

Yet, it seems the Ruby mainstream is content with primitive
servers like unicorn.  I often wonder if the unintentional
popularity of unicorn set the Ruby ecosystem back 5-10 years in
terms of concurrency.  Likely so, but the damage is done :<
In my defense, I suck at marketing, so it's not my fault.


Unicorn was about deploying rails easily for most people, which it really
did. Thin had some other challenges, from the fact that the EM build often
had issues with openssl to unintended buffering issues that are fine for
short requests but very bad for long requests.

Goliath tried, with stronger marketing, to address the concurrency issues,
but Goliath baseline performance was too far behind more basic approaches
to make it a viable option. Anyone who benched their apps and/or didn't
turned explicitly for it will have seen this very clearly.

Anyways, my original post was really a reporting-in-from-hiatus
message.  I haven't done anything new with server design in over
5 years, and don't expect I will in the future; just occasional
janitorial work.  yahns was merely a repackaging and
consolidation of findings from Rainbows! as a "best of" release
with some warts removed.


I'd love to see it happen. I think about doing something periodically, but
for general user use cases its quite a lot of work (as one has to write
good primitives first). I don't really deploy much ruby anymore, my last
bit is probably going away by 2018. Maybe I'll be back, maybe work will
bring me back, but for now, it's someone else race.

Happy Christmas and New years!


--

---
You received this message because you are subscribed to the Google Groups
"Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 6106 bytes --]