4 ms·

I don't think you understand what green threads are. Green threads are simulated threads that run on a single core. https://en.wikipedia.org/wiki/Green_thread

by lisper 4y ago

I don't think you understand what green threads are. Green threads are simulated threads that run on a single core. https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread But you wrote: Multicore CPUs are a fact for life for a long time now. So I assumed that you didn't really want green threads and were just using the wrong terminology. In any case, you can get a Lisp with green threads too, though as you yourself point out that is considered pretty dated technology nowadays.

pdimitar 4y ago
If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers. That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64. The rest is a suboptimal mess and, as already mentioned above, I am not looking to invent my own async [task] orchestration runtime for every project I participate in.
- medo-bear 4y ago
  https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
  - pdimitar 4y ago
    Thanks, that looks promising. Will check out some of the links.
  - Blackthorn 4y ago
    The first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done by the runtime.
    - medo-bear 4y ago
      > They are not transparent what does this mean?
      - Blackthorn 4y ago
        I mean "can it call blocking code without bringing everything to a screeching halt".
        medo-bear 4y ago
        honnest question, can rust? i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism) if you want erlang just use erlang, or a lisp version of it https://lfe.io/ https://lfe.io/
- lisper 4y ago
  > I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elixir's model, or Golang's, or Rust's async workers I'm familiar with those. Those are not "green threads". But whatever you call them, you can do those things in Lisp too.
  - pdimitar 4y ago
    > you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.
    - lisper 4y ago
      The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
      - pdimitar 4y ago
        Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
        lisper 4y ago
        > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.
Blackthorn 4y ago
Nothing implies that green threads need to run on a single core. The summary in your own link is pretty good: "In computer programming, a green thread (virtual thread) is a thread that is scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system (OS)." Which is half of what we're looking for here. A thread that can be managed by the runtime, scheduled onto a native OS thread, and (here's the important part, where Common Lisp falls down on the job), transparently operates like a real thread or in other words, you can make normal blocking operations and the runtime just takes care of it. For example: goroutines
pgwhalen 4y ago
> I don't think you understand what green threads are. Green threads are simulated threads that run on a single core. I guess this is just semantics, but it seems to be that this is an overly narrow and stale definition of green threads. The wikipedia article is not even internally consistent in its definition of green threads necessarily being scheduled only onto a single core (it includes goroutines as an example). The only reference to such a definition cites two sources from the very early 2000's. I think it's safe to say that in 2023 "green threads" simply refers to user space threads rather than kernel threads, and that may include threads scheduled onto multiple cores.

by lisper 4y ago

pdimitar 4y ago

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers. That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64. The rest is a suboptimal mess and, as already mentioned above, I am not looking to invent my own async [task] orchestration runtime for every project I participate in.

medo-bear 4y ago
https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- pdimitar 4y ago
  Thanks, that looks promising. Will check out some of the links.
- Blackthorn 4y ago
  The first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done by the runtime.
  - medo-bear 4y ago
    > They are not transparent what does this mean?
    - Blackthorn 4y ago
      I mean "can it call blocking code without bringing everything to a screeching halt".
      - medo-bear 4y ago
        honnest question, can rust? i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism) if you want erlang just use erlang, or a lisp version of it https://lfe.io/ https://lfe.io/
lisper 4y ago
> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elixir's model, or Golang's, or Rust's async workers I'm familiar with those. Those are not "green threads". But whatever you call them, you can do those things in Lisp too.
- pdimitar 4y ago
  > you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.
  - lisper 4y ago
    The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
    - pdimitar 4y ago
      Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
      - lisper 4y ago
        > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.

Blackthorn 4y ago

Nothing implies that green threads need to run on a single core. The summary in your own link is pretty good: "In computer programming, a green thread (virtual thread) is a thread that is scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system (OS)." Which is half of what we're looking for here. A thread that can be managed by the runtime, scheduled onto a native OS thread, and (here's the important part, where Common Lisp falls down on the job), transparently operates like a real thread or in other words, you can make normal blocking operations and the runtime just takes care of it. For example: goroutines

pgwhalen 4y ago

> I don't think you understand what green threads are. Green threads are simulated threads that run on a single core. I guess this is just semantics, but it seems to be that this is an overly narrow and stale definition of green threads. The wikipedia article is not even internally consistent in its definition of green threads necessarily being scheduled only onto a single core (it includes goroutines as an example). The only reference to such a definition cites two sources from the very early 2000's. I think it's safe to say that in 2023 "green threads" simply refers to user space threads rather than kernel threads, and that may include threads scheduled onto multiple cores.