Hacker News new | past | comments | ask | show | jobs | submit login

I understand, but it isn't enough. You have to have a selective receive primitive to write something like:

    for(;;) { // The main state.
      receive(
        when([](M1 msg1){ // Dive into another state.
          while(some_condition) {
            receive(when([](M2 msg2){...},
              when([](M7 msg7){...},
              ...);
          }
        }),
        when([](M3 msg3){...}),
        when([](M5 msg5){...}),
        ...);
    }
In that case, if you receive M2 before M1 the instance of M2 will be kept in the queue.

But if you have to write something like that:

    for(;;) { // The main state.
      auto * m = receive();
      if(m->type == M1::msg_typeid) { // Dive into another state.
        while(some_condition) {
          auto * m2 = receive();
          if(m2->type == M2::msg_typeid) {...}
          else if(m2->type == M7::msg_typeid){...}
          else if...
        }
      }
      else if(m->type == M3::msg_typeid){...}
      else if(m->type == M5::msg_typeid){...}
      else if...
    }
then you can easily lose a message by a mistake.



if you are tangling msgq-receive with its processing then sure.

however, imho, if you decouple the whole thing i.e. msgq-receive, and its processing via callbacks, then things are harder to get wrong. it might lead to either more elaborate state machine on the receiver side though, but then again imho that is not bad either.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: