[Icecast-dev] [patch] Reopen dumpfiles on signal

[Ken Treis]

I wanted to use the Icecast dumpfile for hourly stream archival, so I added a signal handler to trigger the re-opening of dumpfiles. This lets me rename the dumpfile, signal Icecast, and repeat. Patch is attached.

I've never spent any time in the Icecast source before now, so I had a couple of questions/thoughts:

1. Since all I needed was to trigger a re-open, I went with a new signal & handler (SIGUSR1). But this could have been just as easy to attach to the current HUP handler. In fact, it would have probably been easier, since there'd be no need to duplicate the techniques already used to propagate the message (handler sets global flag, client thread sees flag and triggers event).

2. In my event function, I lock the source tree before iterating it. Is that necessary? I used a read lock, since I'm not modifying the tree structure itself... but while iterating, I set a flag in each source to request that the source re-open its dumpfiles. Does that mean I should have used a write lock instead?

3. I implemented the re-open in source.c rather than in the individual format plugins, which may have been naive of me. I'm dealing strictly with MP3 data here, so I can split the file anywhere. Other formats may not take so kindly to arbitrary stream splits.

I'd love to see this integrated and would be glad to tweak/retool as necessary.

--
Ken Treis
Miriam Technologies, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reopen-dumpfiles.diff
Type: application/octet-stream
Size: 4017 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20110223/beda7eed/attachment.obj