2 ms·

In the early days of Java, threads were actually lightweight threads that were scheduled in user space. They changed them to true OS threads somewhere along the

In the early days of Java, threads were actually lightweight threads that were scheduled in user space. They changed them to true OS threads somewhere along the way, which helps in multiprocessor situations, but I'd love to still have the green threads around as a tool. I don't know enough about the JVM to have any idea how tricky it would be to hack it in; I suspect calling out into a C library that calls setcontext() is going to make the JVM rather unhappy.

davidw 18y ago
Calling out into C or other potentially blocking calls is one of the things Erlang treats very carefully - the scheduler by itself isn't enough. To really make Erlang turn over nicely, you have to isolate contact with external libraries, usually in other Erlang nodes (real, OS level processes). Kind of strange, but very robust.
- pmjordan 18y ago
  It makes sense, really; C code can really mess with managed systems like that, and by the sounds of it, Erlang deals with it gracefully. Unfortunately, the JVM feels a little too monolithic for my liking with regard to processes; it's more unixy than .NET, certainly, and I guess that's the price you pay for a VM that sophisticated.
  - jmtulloss 18y ago
    I wonder if it would be more practical in .NET. They have this idea of Application Domains that I've never needed to fully understand, so never have. Perhaps you could hack that into a Erlang style process model?
    - davidw 18y ago
      The key point is really this: if you call out to some C function, FoobarFunc(), you simply have no guarantees that it won't sit there in a while(1) { fiddlefaddle() } loop. Since Erlang "processes" are all part of the same OS process, that would kill the whole system dead. So you really need to offload things into their own contained little world, which in this case means a real, Unix process, or at the very least a thread.

davidw 18y ago

Calling out into C or other potentially blocking calls is one of the things Erlang treats very carefully - the scheduler by itself isn't enough. To really make Erlang turn over nicely, you have to isolate contact with external libraries, usually in other Erlang nodes (real, OS level processes). Kind of strange, but very robust.

pmjordan 18y ago
It makes sense, really; C code can really mess with managed systems like that, and by the sounds of it, Erlang deals with it gracefully. Unfortunately, the JVM feels a little too monolithic for my liking with regard to processes; it's more unixy than .NET, certainly, and I guess that's the price you pay for a VM that sophisticated.
- jmtulloss 18y ago
  I wonder if it would be more practical in .NET. They have this idea of Application Domains that I've never needed to fully understand, so never have. Perhaps you could hack that into a Erlang style process model?
  - davidw 18y ago
    The key point is really this: if you call out to some C function, FoobarFunc(), you simply have no guarantees that it won't sit there in a while(1) { fiddlefaddle() } loop. Since Erlang "processes" are all part of the same OS process, that would kill the whole system dead. So you really need to offload things into their own contained little world, which in this case means a real, Unix process, or at the very least a thread.