Right! Even though that post is almost 20(!!) years old, Theo is respected enough that you could use that as a rationale for crapping on GCC.
Obviously Theo has his detractors, rightfully so. And the language he uses in that post is not what I would use at all. It's downright unacceptable. But at least it's something - a thing from an authority you can point to and say "this is why!"
reminds me how the other day I circumvented disabled SSH port forwarding by using https://github.com/nwtgck/yamux-cli + ncat already on the machine to do something like:
yamux -l lport | ssh server -- <script: ncat --proxy-type=http -klp proxyport & and yamux localhost proxyport>.sh
good thing I needed HTTP access or else i had to find that socks5 server that's actually working again.
I've been trying to read up on TCP/UDP multiplexing and I'm having a hard time understanding what the use cases are, or advantages over just using regular connections, sockets, and application logic.
Do you have a good resource recommendation to learn this more?
Well here I tunneled multiple TCP connections traffic over a single input/output streams (the SSH shell IO stream).
Basically when you got a single communication channel and it's expensive to create more channels to tunnel multiple TCP streams where each connection get's its on channel, this is when you reach for the muxer.
i.e. here I probably could make it without yamux if instead I used SSH control port(socket? master?) and created many shell IO streams. but using yamux makes it cleaner. Also the server I'm working on is very buggy and you really get like 50% success rate logging in.
I suggest you download this `yamux` utility and play around with it really :)
I also need elaboration on this. I presumed calling lua from c can be used to implement user-defined callbacks. Launching a thread for lua + locking seems even slower?
A bit off topic: I just wrote a bunch of lua C debug api code (lua_sethook) to pre-emptively run and context-switch multiple lua "coroutines" (well not so "co").
Is this library offering a lua implementation more well-designed for this use-case? I got all this code to unload the coroutine stack to store and and reload it before continuing it later. Does having C bindings to this library makes sense?
My understanding is that the "stackless" concept here means that it does not store its execution state in the "C runtime stack" (or Rust, in this case).
So, there is some blob of memory describing that info, managed by Piccolo, rather than it residing on the "real" OS execution stack.
In particular, for call chains like: Lua -> C -> Lua -> C (or so), it is normally hard to save/restore the "C" parts of that chain, since you need to peek into the not-normally-accessible and platform-specific C runtime stack details. I wonder: how are you doing it in your system?
In Piccolo, I imagine it would be easier, since even the "-> C ->" portions of the stack are being managed by Piccolo, not the base C runtime. I don't know what the APIs to access that stuff actually look like, though.
Aside: have you looked at Pluto/Eris for Lua serialization of coroutines?
----
EDIT Yes, it seems like the section The "Big Lie" is right up your alley (:
Well the only thing that's really itching me is the fact that the whole lua debug.* section is documented as
>You should exert care when using this library. Several of its functions violate basic assumptions about Lua code (e.g., that variables local to a function cannot be accessed from outside; that userdata metatables cannot be changed by Lua code; that Lua programs do not crash) and therefore can compromise otherwise secure code
(from the manual)
tbh only like 50% of my `if err != nil { return err }` are mindless. rest of the time, the fact that error handling is explicit and in my face has helped me alot during my time with go.
you wrap those properly. believe me waking up in the middle of the night because someone abused panic to throw state around, end up being called from a new goroutine, just enough to crash the entire pod, sucks even more.
Forgive me as I'm not experienced in Go. I had a look at the API reference for encoding/json[1] and performed a (very hasty) search on the source code[2].
The API reference doesn't state that panics are a part of the expected error interface, and the source code references seem to be using panics as a way to validate invariants. Is that what you're referring to?
I'm not entirely sure if the panics are _just_ for sanity, or if input truly can cause a panic. If it's the latter, then I agree - yikes.
