firstname.lastname@example.org: "[icecast-dev] why is there a timeout in _accept_connection (icecast/src/connection.c)"
msmith at labyrinth.net.au
Wed Feb 26 13:58:28 PST 2003
"k.j.wierenga at home.nl" <k.j.wierenga at 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 at 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
> > 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
> > 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.
--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast-dev