Re: Feature request: plain option for gsub

[Coroutines <coroutines@...>]

On Sat, Aug 23, 2014 at 2:13 PM, William Ahern
<william@25thandclement.com> wrote:

Hmm.  Firstly I think this reply may have been to the wrong thread,
but I appreciate it regardless. :-)

> So there are many instances where serialization makes sense and is much more
> performant. In fact, it'll almost always be faster for short messages that
> fit in cache

Usually I'm taking issue with the objects I must send to a worker
process in Lua, these would not fit anyway... process init sucks :(((

> In any event it's nearly impossible to make use of transactional algorithms
> from a language like Lua. There are no commodity chips currently in
> existence that support primitives like strong LL/SC or even something as
> simple as DCAS (not double-width CAS, but CAS of two non-contiguous
> addresses). If processors had strong LL/SC then we'd be living in a
> concurrency utopia. But lock-free and/or wait-free algorithms on x86 are
> stuck with CAS or double-width CAS and are therefore very simplistic, or
> like RCU require very careful attention to low-level flow control. In
> neither case do they lend themselves to the kind of abstraction that would
> make them easy to expose in a generic manner within a scripting language.

I know some of these words.

> Most of the lock-free algorithm stuff is just hype. I got really excited
> about it 10 years ago. I spend hundreds of dollars on ACM Queue and IEEE
> papers to learn all the algorithms, most of which were discovered in the
> 1980s and early 1990s. Then I learned that almost all modern hardware is
> entirely inadequate to implement most of the well-known transactional
> algorithms. And the few you can implement are seriously hobbled, which makes
> them hard to build abstractions atop. Sure, you can create a lock-free
> singly-linked list. But how do you integrate that into Lua? You can't even
> implement a lock-free doubly-linked list that supports arbitrary element
> insertion; with CAS the best you can do is support insertions/deletions at
> the tails. If you look at "lock-free" trees, etc, they have very narrowly
> tailored usage restrictions. Or RCU. It's insanely difficult to use these
> things because their usage restrictions bleed into almost every aspect of
> your code, much more so than even message passing.

Well.. you've shaken me and now I must go reread what I have found :\
I appreciate hearing this from someone so well-travelled? :3

> So, yeah, tons of hype all around. Depressing, but it's the reality. These
> algorithms can be very useful and very performant, but not as uniformly as
> message passing.

I'd still like to be able to mutate/read userdata from a
single-threaded script.  If we forgo the complications of process
coordination it can still be beneficial for me to avoid reallocating a
network buffer again.  and again.  and again. :>

Thank you for your post <3