k.j.wierenga@home.nl
2004-Aug-06 14:57 UTC
k.j.wierenga@home.nl: "[icecast-dev] why is there a timeout in _accept_connection (icecast/src/connection.c)"
Sorry for replying in this way, I can send to the list ok, but I can't seem to subscribe to the list. majordomo doesn't accept my email address as a valid address (k.j.wierenga@home.nl> This is primarily to allow clean shutdown to proceed normally. The CPUload is> nominal - I doubt you'd be able to measure it. However, if you want tochange> this timeout, it's safe - but if you increase it beyond a few seconds, > shutdown will take an excessively long time. This won't be changed in the > standard version of icecast (though if you can give a convincing reasonto> increase it slightly, I might). > > MikeCan you explain in a bit more detail why the shutdown would take so long? There are other ways to get the code to break out of the select/poll system call. A user defined signal springs to mind... Then select/poll would return -1 and errno would be set to EINTR. You can then simply ignore this error and go around the loop. KJ <p><p><p>-------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Michael Smith
2004-Aug-06 14:57 UTC
k.j.wierenga@home.nl: "[icecast-dev] why is there a timeout in _accept_connection (icecast/src/connection.c)"
"k.j.wierenga@home.nl" <k.j.wierenga@home.nl> said:> Sorry for replying in this way, I can send to the list ok, but I can't seem > to subscribe to the list. majordomo doesn't accept my email address as a > valid address (k.j.wierenga@home.nl > > > This is primarily to allow clean shutdown to proceed normally. The CPU > load is > > nominal - I doubt you'd be able to measure it. However, if you want to > change > > this timeout, it's safe - but if you increase it beyond a few seconds, > > shutdown will take an excessively long time. This won't be changed in the > > standard version of icecast (though if you can give a convincing reason > to > > increase it slightly, I might). > > > > Mike > > Can you explain in a bit more detail why the shutdown would take so long? > There are other ways to get the code to break out of the select/poll system > call. A user defined signal springs to mind... Then select/poll would > return -1 and errno would be set to EINTR. You can then simply ignore this > error and go around the loop. >Getting signals to work right - reliably AND portably - in a multithreaded program is difficult at best. If you want to contribute a patch, I'd be happy to accept it, but I'm not going to do it for a theoretical (almost certainly unmeasurable) reduction in cpu usage. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Maybe Matching Threads
- why is there a timeout in _accept_connection (icecast/src/connection.c)
- FW: Multi-Level Fallbacks
- icecast performance on many concurrentlow-bitrate streams
- FW: Tip: using icecast in chroot mode may break timestamp inaccess.log
- icecast performance on manyconcurrentlow-bitrate streams