Well, it's not *so* dangerous as there is no reason for bpmclock to stop unexpectedly (never happened on my side, and it's such a small piece of code I don't see what could happen). If it works, why fix it? If you could report an occurrence of such a crash, I would try to find a solution, but I don't see it as a major issue atm. Other thoughts about that problem: We cannot assume bpmdj is running when running bpmplay, so if bpmplay is started stand-alone, it must fork bpmclock, and bpmclock runs as long as it has clients (bpmplay or bpmdj), so again we should not run into trouble. One solution could be that the forking process is responsible for initializing the shared memory instead of bpmclock, but I'm not convinced it would make such a huge difference.
Actually this is not the only dangerous situation. If I understand it correct: you check whether there is a clockdriver and when there is none you start your own, however between checking and actually using it it could have dissapeared. Maybe it would be better not to use this pseudo intelligent 'create when necessary' approach. If bpmdj start it can spawn the external clock, which should then also not quit independently but wait until it receives the quit signal.)
/* we need to wait for bpmclock to initialize the shared memory */ sleep(2); This is definitely a bad idea. IS there no other solution like waiting until a certain flag gets set in the shared memory or so ?