>>> >>>This whole mechanism seems very error prone. Is it possible to hang a >>>thread with the subsequent sem_post? >> >> The relay function is called by 'ovs_keepalive' thread. I didn't >> completely understand your concerns here. I would be happy to verify >> if you have any scenarios in mind that you think pose problems. > >My concern stems from this: > "is relayed to monitoring framework by unlocking the semaphore." > >Assume the OvS vswitchd crashes while another process is pended on this >locked semaphore. Since you do a shm_unlink, I think the pended process >waiting on that semaphore will be stuck. Even worse, since we do have a >process left with a handle, the name will be unlinked, and the memory and >reading process (which may be ceilometer, but may be something else) will be >left orphaned waiting for an update so that they can destroy it. > >There's a lot of coordination that needs to be added here, and it's likely not >portable. I'm not even sure if there are examples where it has been shown to >work 100% on specific systems. > >A much better design is to use a socket to share state. Since it is tied to >the >lifetime of a process, and cleanup is guaranteed by POSIX (and all sane OSes, >anyway) you can rely on it. It is a much better mechanism for signaling >changes, and a message based interface means you can make this dump >information to _any_ interested subscriber - even those who are off system if >you choose. >
Thanks Aaron for clarifying this and appreciate all your feedback on this patch series. I shall try out the scenarios leading to unexpected crashes and see how well the applications recover on a restart and check for any further shortcomings. - Bhanuprakash. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
