6 ms·

After learning about effect systems, and generalising effects, my view on `setjmp` has changed considerably -- it seems effect systems "effectively" offer a des

After learning about effect systems, and generalising effects, my view on `setjmp` has changed considerably -- it seems effect systems "effectively" offer a design pattern for their use in languages without them. ie., it feels that there's an async-await.h, try-catch.h, etc. to be written which would serve as c-ish design patterns. I'd be interested, then, in to what degree other langs can do the same. As a side point, i've not yet read a good defence of why programming in C is so fun and satisfying in this way. People reduce the Rust/C issue to memory saftey... but isn't there something inherently wonderful about `while(*this++ = *that++)` (etc. etc.) ? (A sense of fun beaten out of you by too many annotation guaranteeing its saftey?)

flohofwoe 4y ago
These days the 'fashionable' way to implement async-await seems to be via compiler magic by transforming async functions into a 'switch-case state machine' and a hidden context pointer argument. In vanilla C (without compiler magic) I've mostly seen it implemented via 'green threads' aka 'fibers' aka 'stack-switching', but TBH I'm not sure if this can be implemented with the standard setjmp/longjmp, I've mostly seen it implemented without (and instead use two small assembly functions for the context switch). One downside of stack-switching is that it doesn't work on WASM.
- chaosite 4y ago
  stack switching with setjmp/longjmp can be implemented like this: https://stackoverflow.com/a/8817009/1116739 https://stackoverflow.com/a/8817009/1116739 But it's messy enough that you'd want a library/framework to help you handle it.
  - mananaysiempre 4y ago
    POSIX pre-2008 had (and Linux/Glibc and {Free,Net,DragonFly}BSD still have) <ucontext.h> with proper stack switching functions, used as a fallback in a number of coroutine libraries. The fallback status is due to a self-inflicted inefficiency: they save and restore the signal mask, thus still need to go through the kernel (why e.g. Linux does not put signal mask manipulation in the vDSO, I don’t know). POSIX yanked them and now recommends rewriting to use POSIX threads instead, which is asinine.
    - gpderetta 4y ago
      And the 2008 was about the time that coroutines were gaining popularity again!
  - Findecanor 4y ago
    Putting each tasklet's stack in different places on the actual stack and jumping between them is inherently unsafe and not portable. You must be sure that each tasklet does not consume too much stack so that it does not overwrite another. On BSD Unices, you can only longjump back up the stack. Otherwise, longjmp() will call longjmperror() and terminate the program.
    - chaosite 4y ago
      > Putting each tasklet's stack in different places on the actual stack and jumping between them is inherently unsafe and not portable. You must be sure that each tasklet does not consume too much stack so that it does not overwrite another. It's absolutely unsafe and a ridiculous to do, but what's the reasoning for it being unportable? Wouldn't it just be just as unsafe anywhere that C compiles? > On BSD Unices, you can only longjump back up the stack. Otherwise, longjmp() will call longjmperror() and terminate the program. The manpage claims that the semantics is not "only jump back up the stack", but rather that you can't longjmp to "[...] an environment that that has already returned". Technically, the tasklet the we're longjmp'ing to never terminates, right?
      - comex 4y ago
        In any case, you definitely can't do it on Windows and Emscripten (WebAssembly), where longjmp invokes the same stack unwinding behavior as C++ exception handling, rather than just setting some registers and jumping. Windows has its own APIs for tasklets (fibers); no such luck on Emscripten.
- samsquire 4y ago
  I wrote an unrolled switch statement in Java to simulate eager async/await across threads. https://github.com/samsquire/multiversion-concurrency-control/blob/main/src/main/java/main/MultiAwait.java https://github.com/samsquire/multiversion-concurrency-contro... The goal is that a compiler should generate this for you. This code is equivalent to the following: task1: while True: handle1 = async task2(); handle2 = async task3(); print(await handle1) print(await handle2) task2: n = 0 while True: yield n++ task3: n = 0 while True: yield n++ It doesn't actually run task2 and task3 both eagerly, I've not got around to scheduling the tasks on DIFFERENT threads. They currently queue onto a single thread, so task2 and task3 are parallel to task1 (but maybe not at the same time) but task2 and task3 are not parallel to each other. This is my goal. I also ported the coroutines in this blog post https://blog.dziban.net/coroutines/ https://blog.dziban.net/coroutines/ to GNU Assembler https://github.com/samsquire/assembly/blob/main/coroutines.S https://github.com/samsquire/assembly/blob/main/coroutines.S This might be useful to someone who wants to port this to C. This uses the stack switching idea. So they are stackful coroutines. There's also Tina a header only coroutine library https://slembcke.github.io/Tina https://slembcke.github.io/Tina I also played with protothreads http://dunkels.com/adam/pt/ http://dunkels.com/adam/pt/ I also asked in a stackoverflow post how to use a thread pool with C++20 coroutines: https://stackoverflow.com/questions/74520133/how-can-i-pass-things-to-a-c20-coroutine-co-await-await-suspend-operator-funct https://stackoverflow.com/questions/74520133/how-can-i-pass-... Someone provided some example code, which seems to work with C++ coroutines :-)
- duped 4y ago
  The big problem with setjmp/longjmp for fibers is that a call to longjmp is undefined behavior if the `jmp_buf` argument was created by a call to `setjmp` on a different thread (1). That means fibers cannot be easily relocated onto a different thread, making M:N threading tricky to implement and erasing a lot of the benefit of fibers. And that said, implementing a super-fast setcontext/swapcontext is like twenty lines of assembly with not too many gotchas, if you don't care about saving a few things that require syscalls. But all that said the real downside of stack switching is that it's overkill for coroutines that can be implemented as a finite state machine, unless the runtime supports growable stacks (otherwise you pay a big cost on fiber creation, and eat a lot of memory for many fibers). There are a few languages that do this and it's super cool, but C isn't one of them. WASM will almost certainly support stack switching, iirc there have been proposals for wasmtime to support it already? (1) https://pubs.opengroup.org/onlinepubs/9699919799/functions/longjmp.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/l...
  - lstodd 4y ago
    > And that said, implementing a super-fast setcontext/swapcontext is like twenty lines of assembly with not too many gotchas, if you don't care about saving a few things that require syscalls. sigaltstack(2) wasn't all that prohibitive when I did that in Python 2.6 back then. Was it 2009? I seriously can't understand this obsession with FSMs. A naive setcontext()-based implementation outperfomed both greenlets (with its crazy legacy of memcpy-ing parts of stack from stackless) and Tornado/Twisted (with them being pure-python and therefore lacking any means to force some async on client libraries. which one does in C) while letting everyone write some nice clean synchronous-looking code. 10 years later we end up with half a language hacked up and still nowhere near the ease of use that was coded in a week or so.
    - duped 4y ago
      > I seriously can't understand this obsession with FSM It's the most optimal representation of the common-case (non-recursive asynchronous tasks), has the same overhead as a function call, plays very well with branch prediction, can be easily inlined by optimizers, and it's a lot easier to implement.
ckastner 4y ago
> inherently wonderful about `while(*this++ = *that++)` As someone who hasn't used C as a primary language in some project for over a decade, I read this and (1) realize that LHS and RHS both post-increment, (2) don't remember if there is some UB I might be overlooking, (3) realize that the operator is assignment "=", not comparison "==", and I can't even remember what the loop termination criterion here would be. Until "*that++" is equivalent to false, or something? It may be beautiful to the experienced programmer, but I personally would consider this just "clever" (which is a criticism, not a compliment). It feels like someone needlessly tried to pack everything into a single line of code. This is something I'd write out more verbosely, if only to make reading it simpler. The compiler will probably generate the same machine code either way. I'm fully aware that to the seasoned C developer, my criticism might come across as naive. However, even the fully seasoned C developer can get careless, or become tired, and in C, every one of those little things can come back and bite you in those situations. Edit: removed the double pointer dereferencing remark, must have been an artifact from HN's special treatment of the asterisk. Edit-Edit: I was probably wrong. I don't think it's possible to create a more verbose version without it affecting performance.
- flohofwoe 4y ago
  It's entirely valid C and (assuming this and that are byte pointers) copies a range of bytes until (and including) a zero byte is reached. With a suffficient warning level (e.g. -Wall on gcc, which should always be enabled anyway, together with -Wextra), compilers will complain about the '=' and ask you to add a pair of braces to make clear that this is actually intended: while( (*this++ = *that++) ); It's also one of those cases where the C code matches the output assembly pretty well: https://www.godbolt.org/z/nz1jbz4Er https://www.godbolt.org/z/nz1jbz4Er As far as "obfuscated C" goes, this is a very tame example though, it's just a straightforward usage of language features, which might look strange only when coming from other languages that don't have pointers or a post-increment operator).
  - ckastner 4y ago
    Doesn't that kind of prove my point? The code as written was described as beautiful, yet would not have passed -Wall. It's those little things that can easily get you in C, and there are so many little things to consider.
naasking 4y ago
You might be interested in libhandler: https://github.com/koka-lang/libhandler https://github.com/koka-lang/libhandler Basically an effect handling library for C written by the folks developing the koka language.
anonymousiam 4y ago
I once took an "Advanced C Programming" class (which would have been better named as "How to do OOP in a language never intended for it") where the instructor expressly prohibited the use of "*i++" and several other language elements because he thought they were confusing. I got into many arguments with the instructor throughout the course, and I figured I would get a poor grade, but he still gave me an A. My main disagreement with him was this: If the language elements are there and well defined, why prohibit their use? The course after all was "Advanced C", wasn't it?
- badsectoracula 4y ago
  That has been my argument for "preprocessor abuse" - there isn't such thing as preprocessor "abuse"[0], it is part of the language and provides some form of extensibility in a language with an already limited set of features. If anything the preprocessor needs more features (let me include files from macros and do loops dammit :-P). [0] ok, i can think of some uses that might count, like "#define BEGIN {", etc that serve no practical purpose, but i don't think anyone called these "preprocessor abuse".
  - kevin_thibedeau 4y ago
    You can have all that with m4. It's a perfectly suitable C preprocessor.
    - badsectoracula 4y ago
      m4 is a bit weird but if you can use that you can use any preprocessor - including a custom one. The issue is that chances are said preprocessor wont work with editors and IDEs that can parse C to provide tools like syntax completion, jumping to definitions, etc - if anything you'd be lucky if you get working line numbers t use a debugger with.
- Karellen 4y ago
  "Programs must be written for people to read, and only incidentally for machines to execute" -- Abelson & Sussman, Structure and Interpretation of Computer Programs, 1984. It's possible to write English with bad structure, clumsy metaphors, obscure vocabulary, and non-non-non-usual idiosyncrasies. And other people might be technically capable of understanding it if they really want to, and try hard enough. After all, the language elements are there and well-defined, so why would anyone ever complain about "bad" writing? (Out of curiosity, do you object to people who say the use of "goto" should be seriously restricted, or even prohibited, in most programs? Do you specifically use gotos to make the point that they can still be be useful and productive? The language element is there and well-defined.)
lisper 4y ago
> isn't there something inherently wonderful about `while(this++ = that++)` (etc. etc.) ? There is something inherently wonderful about riding a motorcycle without a helmet too. That doesn't mean it is wise.
tomcam 4y ago
About your last two questions yes and yes. I love C.

flohofwoe 4y ago

These days the 'fashionable' way to implement async-await seems to be via compiler magic by transforming async functions into a 'switch-case state machine' and a hidden context pointer argument. In vanilla C (without compiler magic) I've mostly seen it implemented via 'green threads' aka 'fibers' aka 'stack-switching', but TBH I'm not sure if this can be implemented with the standard setjmp/longjmp, I've mostly seen it implemented without (and instead use two small assembly functions for the context switch). One downside of stack-switching is that it doesn't work on WASM.

chaosite 4y ago
stack switching with setjmp/longjmp can be implemented like this: https://stackoverflow.com/a/8817009/1116739 https://stackoverflow.com/a/8817009/1116739 But it's messy enough that you'd want a library/framework to help you handle it.
- mananaysiempre 4y ago
  POSIX pre-2008 had (and Linux/Glibc and {Free,Net,DragonFly}BSD still have) <ucontext.h> with proper stack switching functions, used as a fallback in a number of coroutine libraries. The fallback status is due to a self-inflicted inefficiency: they save and restore the signal mask, thus still need to go through the kernel (why e.g. Linux does not put signal mask manipulation in the vDSO, I don’t know). POSIX yanked them and now recommends rewriting to use POSIX threads instead, which is asinine.
  - gpderetta 4y ago
    And the 2008 was about the time that coroutines were gaining popularity again!
- Findecanor 4y ago
  Putting each tasklet's stack in different places on the actual stack and jumping between them is inherently unsafe and not portable. You must be sure that each tasklet does not consume too much stack so that it does not overwrite another. On BSD Unices, you can only longjump back up the stack. Otherwise, longjmp() will call longjmperror() and terminate the program.
  - chaosite 4y ago
    > Putting each tasklet's stack in different places on the actual stack and jumping between them is inherently unsafe and not portable. You must be sure that each tasklet does not consume too much stack so that it does not overwrite another. It's absolutely unsafe and a ridiculous to do, but what's the reasoning for it being unportable? Wouldn't it just be just as unsafe anywhere that C compiles? > On BSD Unices, you can only longjump back up the stack. Otherwise, longjmp() will call longjmperror() and terminate the program. The manpage claims that the semantics is not "only jump back up the stack", but rather that you can't longjmp to "[...] an environment that that has already returned". Technically, the tasklet the we're longjmp'ing to never terminates, right?
    - comex 4y ago
      In any case, you definitely can't do it on Windows and Emscripten (WebAssembly), where longjmp invokes the same stack unwinding behavior as C++ exception handling, rather than just setting some registers and jumping. Windows has its own APIs for tasklets (fibers); no such luck on Emscripten.
samsquire 4y ago
I wrote an unrolled switch statement in Java to simulate eager async/await across threads. https://github.com/samsquire/multiversion-concurrency-control/blob/main/src/main/java/main/MultiAwait.java https://github.com/samsquire/multiversion-concurrency-contro... The goal is that a compiler should generate this for you. This code is equivalent to the following: task1: while True: handle1 = async task2(); handle2 = async task3(); print(await handle1) print(await handle2) task2: n = 0 while True: yield n++ task3: n = 0 while True: yield n++ It doesn't actually run task2 and task3 both eagerly, I've not got around to scheduling the tasks on DIFFERENT threads. They currently queue onto a single thread, so task2 and task3 are parallel to task1 (but maybe not at the same time) but task2 and task3 are not parallel to each other. This is my goal. I also ported the coroutines in this blog post https://blog.dziban.net/coroutines/ https://blog.dziban.net/coroutines/ to GNU Assembler https://github.com/samsquire/assembly/blob/main/coroutines.S https://github.com/samsquire/assembly/blob/main/coroutines.S This might be useful to someone who wants to port this to C. This uses the stack switching idea. So they are stackful coroutines. There's also Tina a header only coroutine library https://slembcke.github.io/Tina https://slembcke.github.io/Tina I also played with protothreads http://dunkels.com/adam/pt/ http://dunkels.com/adam/pt/ I also asked in a stackoverflow post how to use a thread pool with C++20 coroutines: https://stackoverflow.com/questions/74520133/how-can-i-pass-things-to-a-c20-coroutine-co-await-await-suspend-operator-funct https://stackoverflow.com/questions/74520133/how-can-i-pass-... Someone provided some example code, which seems to work with C++ coroutines :-)
duped 4y ago
The big problem with setjmp/longjmp for fibers is that a call to longjmp is undefined behavior if the `jmp_buf` argument was created by a call to `setjmp` on a different thread (1). That means fibers cannot be easily relocated onto a different thread, making M:N threading tricky to implement and erasing a lot of the benefit of fibers. And that said, implementing a super-fast setcontext/swapcontext is like twenty lines of assembly with not too many gotchas, if you don't care about saving a few things that require syscalls. But all that said the real downside of stack switching is that it's overkill for coroutines that can be implemented as a finite state machine, unless the runtime supports growable stacks (otherwise you pay a big cost on fiber creation, and eat a lot of memory for many fibers). There are a few languages that do this and it's super cool, but C isn't one of them. WASM will almost certainly support stack switching, iirc there have been proposals for wasmtime to support it already? (1) https://pubs.opengroup.org/onlinepubs/9699919799/functions/longjmp.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/l...
- lstodd 4y ago
  > And that said, implementing a super-fast setcontext/swapcontext is like twenty lines of assembly with not too many gotchas, if you don't care about saving a few things that require syscalls. sigaltstack(2) wasn't all that prohibitive when I did that in Python 2.6 back then. Was it 2009? I seriously can't understand this obsession with FSMs. A naive setcontext()-based implementation outperfomed both greenlets (with its crazy legacy of memcpy-ing parts of stack from stackless) and Tornado/Twisted (with them being pure-python and therefore lacking any means to force some async on client libraries. which one does in C) while letting everyone write some nice clean synchronous-looking code. 10 years later we end up with half a language hacked up and still nowhere near the ease of use that was coded in a week or so.
  - duped 4y ago
    > I seriously can't understand this obsession with FSM It's the most optimal representation of the common-case (non-recursive asynchronous tasks), has the same overhead as a function call, plays very well with branch prediction, can be easily inlined by optimizers, and it's a lot easier to implement.

ckastner 4y ago

> inherently wonderful about `while(*this++ = *that++)` As someone who hasn't used C as a primary language in some project for over a decade, I read this and (1) realize that LHS and RHS both post-increment, (2) don't remember if there is some UB I might be overlooking, (3) realize that the operator is assignment "=", not comparison "==", and I can't even remember what the loop termination criterion here would be. Until "*that++" is equivalent to false, or something? It may be beautiful to the experienced programmer, but I personally would consider this just "clever" (which is a criticism, not a compliment). It feels like someone needlessly tried to pack everything into a single line of code. This is something I'd write out more verbosely, if only to make reading it simpler. The compiler will probably generate the same machine code either way. I'm fully aware that to the seasoned C developer, my criticism might come across as naive. However, even the fully seasoned C developer can get careless, or become tired, and in C, every one of those little things can come back and bite you in those situations. Edit: removed the double pointer dereferencing remark, must have been an artifact from HN's special treatment of the asterisk. Edit-Edit: I was probably wrong. I don't think it's possible to create a more verbose version without it affecting performance.

flohofwoe 4y ago
It's entirely valid C and (assuming this and that are byte pointers) copies a range of bytes until (and including) a zero byte is reached. With a suffficient warning level (e.g. -Wall on gcc, which should always be enabled anyway, together with -Wextra), compilers will complain about the '=' and ask you to add a pair of braces to make clear that this is actually intended: while( (*this++ = *that++) ); It's also one of those cases where the C code matches the output assembly pretty well: https://www.godbolt.org/z/nz1jbz4Er https://www.godbolt.org/z/nz1jbz4Er As far as "obfuscated C" goes, this is a very tame example though, it's just a straightforward usage of language features, which might look strange only when coming from other languages that don't have pointers or a post-increment operator).
- ckastner 4y ago
  Doesn't that kind of prove my point? The code as written was described as beautiful, yet would not have passed -Wall. It's those little things that can easily get you in C, and there are so many little things to consider.

naasking 4y ago

You might be interested in libhandler: https://github.com/koka-lang/libhandler https://github.com/koka-lang/libhandler Basically an effect handling library for C written by the folks developing the koka language.

anonymousiam 4y ago

I once took an "Advanced C Programming" class (which would have been better named as "How to do OOP in a language never intended for it") where the instructor expressly prohibited the use of "*i++" and several other language elements because he thought they were confusing. I got into many arguments with the instructor throughout the course, and I figured I would get a poor grade, but he still gave me an A. My main disagreement with him was this: If the language elements are there and well defined, why prohibit their use? The course after all was "Advanced C", wasn't it?

badsectoracula 4y ago
That has been my argument for "preprocessor abuse" - there isn't such thing as preprocessor "abuse"[0], it is part of the language and provides some form of extensibility in a language with an already limited set of features. If anything the preprocessor needs more features (let me include files from macros and do loops dammit :-P). [0] ok, i can think of some uses that might count, like "#define BEGIN {", etc that serve no practical purpose, but i don't think anyone called these "preprocessor abuse".
- kevin_thibedeau 4y ago
  You can have all that with m4. It's a perfectly suitable C preprocessor.
  - badsectoracula 4y ago
    m4 is a bit weird but if you can use that you can use any preprocessor - including a custom one. The issue is that chances are said preprocessor wont work with editors and IDEs that can parse C to provide tools like syntax completion, jumping to definitions, etc - if anything you'd be lucky if you get working line numbers t use a debugger with.
Karellen 4y ago
"Programs must be written for people to read, and only incidentally for machines to execute" -- Abelson & Sussman, Structure and Interpretation of Computer Programs, 1984. It's possible to write English with bad structure, clumsy metaphors, obscure vocabulary, and non-non-non-usual idiosyncrasies. And other people might be technically capable of understanding it if they really want to, and try hard enough. After all, the language elements are there and well-defined, so why would anyone ever complain about "bad" writing? (Out of curiosity, do you object to people who say the use of "goto" should be seriously restricted, or even prohibited, in most programs? Do you specifically use gotos to make the point that they can still be be useful and productive? The language element is there and well-defined.)

lisper 4y ago

> isn't there something inherently wonderful about `while(this++ = that++)` (etc. etc.) ? There is something inherently wonderful about riding a motorcycle without a helmet too. That doesn't mean it is wise.

tomcam 4y ago

About your last two questions yes and yes. I love C.