5 ms·

Defers are still called when the stack is unwound due to a panic. It's standard practise to clean up resources with a defer, so maybe it wouldn't be too unreaso

by pushrax 12y ago

Defers are still called when the stack is unwound due to a panic. It's standard practise to clean up resources with a defer, so maybe it wouldn't be too unreasonable if you're mainly dealing with the standard libraries.

jacquesm 12y ago
Would you bet your phone switchboard, nuclear plant or assembly line to that strategy? Go is very much a work in development, it is a vast improvement over C but I highly doubt that this strategy will get you out of every corner case. It might get you from 'crash now' to 'crash a (little) while later' but I think you will still end up having an unpredictable element in there. It all depends on how ugly the crash is and once things become unpredictable leakage (even between go-routines) is not to be ruled out categorically. Think of erlang processes to be about as well isolated as unix processes and think of go processes to be a bit more isolated than unix threads but not much more. The trick here is that erlang is essentially an OS inside a process and that go-routines are co-operative multi-tasking inside a process aided by one or more cpu threads. That's a lot closer to the C multi-threading model than erlang and that implies there are some risks.
- troutwine 12y ago
  It's worth noting that Erlang is only a soft-realtime language. I wouldn't bet my nuclear plant and only some assembly lines on it. (There's plenty I do bet on Erlang, though.)
  - jacquesm 12y ago
    That's valid, hard real time problems require guarantees that erlang can't give, that was an unwarranted exaggeration on my part. But anything that needs to be very long running (years or more) will need ironclad guarantees that it won't be leaking resources and I can't prove but suspect that erlang will do a lot better than go for those applications. Let's leave the nuclear plants and the assembly lines to RTos and QnX then :).
    - peerst 12y ago
      "require guarantees that erlang can't give" ... at the moment, working on it. In the meantime note that the percentage of stuff that really needs hard realtime in many systems is quite low. What I do at the moment is run Erlang on RTEMS (see my other posts) keep the hard realtime parts as simple as possible (always a good idea), write them in C and run them on a higher prio than the Erlang runtime which handles all the complicated things. Works like a breeze in practice
  - phamilton 12y ago
    I wonder whether Erlang insome form could provide hard realtime guarantees. Something along the lines of LING.
    - troutwine 12y ago
      It's an interesting question. I think you'd need at least: * a way to define scheduling requirements on a process level (beyond current, coarse, priority settings), * bounded process message queues (this would be handy in soft-realtime Erlang), * deadline accurate receives, * accurate control over resource allocation I've been meaning to sit down with some theory and think through this more analytically, but the above are my BART thinking-time derived set of requirements. I'm sure there are cases--some which would be obvious, in retrospect--that are not covered by the above.
      - jacquesm 12y ago
        You'd have to run erlang directly on the hardware without an intermediary OS and you'd have to schedule the individual erlang processes using pre-emption and by giving them priorities. You'd also have to add a ready-list per priority. After all, as long as BEAM is running as a child process of a host os that is not hard realtime you can't guarantee much of anything.
        troutwine 12y ago
        Of course. Apologies, I assumed that was a given. A large part of the appeal of Erlang the Language is Erlang the VM and the two aren't often divorced.
        peerst 12y ago
        Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org http://www.grisp.org Hard realtime processes to come
        phamilton 12y ago
        Yeah, that's what I meant with LING (Erlang on xen).
  - peerst 12y ago
    Soft is the new hard ;-) If you reason about hard realtime you pretty soon end up with the question: how high can the probability be that it misses a deadline. If you run on modern embedded CPU's with pipelines and caches its often all you can do (I am aware that some are modeling the CPU with caches, memory and everything to achieve 100% but thats very expensive and if you switch CPU's there is half a year worth of modeling down the drain) The real world hard realtime systems often are built like: lets test it (with deadline miss triggering a failure) and if it works make sure we still have 10% of safety margin (which will later be melted down because of features ;-)

by pushrax 12y ago

jacquesm 12y ago

Would you bet your phone switchboard, nuclear plant or assembly line to that strategy? Go is very much a work in development, it is a vast improvement over C but I highly doubt that this strategy will get you out of every corner case. It might get you from 'crash now' to 'crash a (little) while later' but I think you will still end up having an unpredictable element in there. It all depends on how ugly the crash is and once things become unpredictable leakage (even between go-routines) is not to be ruled out categorically. Think of erlang processes to be about as well isolated as unix processes and think of go processes to be a bit more isolated than unix threads but not much more. The trick here is that erlang is essentially an OS inside a process and that go-routines are co-operative multi-tasking inside a process aided by one or more cpu threads. That's a lot closer to the C multi-threading model than erlang and that implies there are some risks.

troutwine 12y ago
It's worth noting that Erlang is only a soft-realtime language. I wouldn't bet my nuclear plant and only some assembly lines on it. (There's plenty I do bet on Erlang, though.)
- jacquesm 12y ago
  That's valid, hard real time problems require guarantees that erlang can't give, that was an unwarranted exaggeration on my part. But anything that needs to be very long running (years or more) will need ironclad guarantees that it won't be leaking resources and I can't prove but suspect that erlang will do a lot better than go for those applications. Let's leave the nuclear plants and the assembly lines to RTos and QnX then :).
  - peerst 12y ago
    "require guarantees that erlang can't give" ... at the moment, working on it. In the meantime note that the percentage of stuff that really needs hard realtime in many systems is quite low. What I do at the moment is run Erlang on RTEMS (see my other posts) keep the hard realtime parts as simple as possible (always a good idea), write them in C and run them on a higher prio than the Erlang runtime which handles all the complicated things. Works like a breeze in practice
- phamilton 12y ago
  I wonder whether Erlang insome form could provide hard realtime guarantees. Something along the lines of LING.
  - troutwine 12y ago
    It's an interesting question. I think you'd need at least: * a way to define scheduling requirements on a process level (beyond current, coarse, priority settings), * bounded process message queues (this would be handy in soft-realtime Erlang), * deadline accurate receives, * accurate control over resource allocation I've been meaning to sit down with some theory and think through this more analytically, but the above are my BART thinking-time derived set of requirements. I'm sure there are cases--some which would be obvious, in retrospect--that are not covered by the above.
    - jacquesm 12y ago
      You'd have to run erlang directly on the hardware without an intermediary OS and you'd have to schedule the individual erlang processes using pre-emption and by giving them priorities. You'd also have to add a ready-list per priority. After all, as long as BEAM is running as a child process of a host os that is not hard realtime you can't guarantee much of anything.
      - troutwine 12y ago
        Of course. Apologies, I assumed that was a given. A large part of the appeal of Erlang the Language is Erlang the VM and the two aren't often divorced.
      - peerst 12y ago
        Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org http://www.grisp.org Hard realtime processes to come
      - phamilton 12y ago
        Yeah, that's what I meant with LING (Erlang on xen).
- peerst 12y ago
  Soft is the new hard ;-) If you reason about hard realtime you pretty soon end up with the question: how high can the probability be that it misses a deadline. If you run on modern embedded CPU's with pipelines and caches its often all you can do (I am aware that some are modeling the CPU with caches, memory and everything to achieve 100% but thats very expensive and if you switch CPU's there is half a year worth of modeling down the drain) The real world hard realtime systems often are built like: lets test it (with deadline miss triggering a failure) and if it works make sure we still have 10% of safety margin (which will later be melted down because of features ;-)