On 2014/11/30 20:20, Piotr Koz??owski <pi...@pkozlowski.pl> wrote: > > Use of sleep() is unacceptable. > > Could you explain why? I've seen usage of usleep() in other parts of > the code - would it be better here? Otherwise what do you suggest? I'm > new to MPD development, so any advice is welcome.
All uses of usleep() are bad and must be removed. This is either legacy code or code submitted from people who disappeared without cleaning up their mess. That's why I don't like to merge "unclean" code anymore. sleep() blocks the whole thread. It's bad style in general for all but very simple (non-interactive) programs, not just specific to MPD. If you ever want to try to connect after a certain amount of time, schedule a timer event, and do it in the event callback. That way, other I/O can be handled while the "sleep time" passes. > > But why do you have to start MPD? > > Normally MPD is started through System-V init scripts, but if the > startup fails (due to connection problems), it will not be > restarted. Why would startup fail? Isn't this the real problem that should be solved? > That's why I have to ssh and start MPD manually. > > > And why does your wifi network fail to transmit the first packet? I don't > > think I'll merge this patch, even with sleep() removed. > > I'm not sure about that - when I try to ping the other host after boot > up, the first packet is lost, the second one arrives with an huge > delay (1-2 seconds), and than following are transmitted correctly (few > ms delay). But I don't think this is the right place to discuss issues > of my home network. It is not the place, you're right, but for one thing it is interesting: to find out whether your patch is the right approach to your problem. I'm still unconvinced. _______________________________________________ mpd-devel mailing list mpd-devel@musicpd.org http://mailman.blarg.de/listinfo/mpd-devel
