gross negligance of interfaces
Ed Sweetman <[email protected]>
| Newsgroups | gmane.comp.audio.zinf.devel |
|---|---|
| Message-ID | <[email protected]> |
The lmc obviously has issues with adhering to zinf interfaces. Fixing the problem most likely will involve a lot of editing in the lmc plugins to remove the crap that bypasses the interfaces of the pipeline. This is a good chance for anyone who maybe hasn't read literally every line of code in zinf at least once to get something necessary done. I'm already rewriting the vorbis plugin because it HAS to be rewritten so if i'm left to edit the other plugins as well it's going to take some time to do. It would be nice to coordinate work of removing interface breaking code that i've found with people who can work on the other plugins while i'm doing the vorbis one. It would also be nice if the other regular developers of zinf give a heads up on their current direction of work so we can coordinate efforts to stomp bugs and clean up the code. I'm working on the pipeline deadlock of which is caused soley by the vorbis plugin and our not handling callback errors which as it happens is in complete gross violation of pipeline interfaces anyway so to fix the vorbis plugin i have to rewrite it completely. In the process i've recently found (even though i've read or edited nearly every single source file in zinf before) that every lmc plugin seems to have code that completely violates the pipeline interface. It's hard enough to debug a threaded app and get locks correct, it's even harder when the thing doesn't work the way it's supposed to. Regardless of the difficulty of debugging a program that doesn't follow it's own design, interfaces MUST be followed, with no exceptions, and these "nasty hacks" as it's put in the headers of some of these files must be removed and if necessary/able replaced with code that follows the pipeline interfaces. I'm trying not to be spread too thin by extending the problem out too far with what interfaces zinf violates and that, i'm focused only on the problem of pipeline deadlocks so this is my plan. After i code the vorbis plugin (which is still nearly done, had test today so it was on hold) and test to see if the current locking structure and fixes work completely i'll submit that patch. Then if nobody else has stepped up to the plate to fix the other plugins, i will have to work on those because fixing these plugins could cause unforseeable issues with deadlocks in the pipeline so my pipeline locking goal is not going to be done until all the plugins are in a state at least adhering to interfaces. (The locking fixes besides vorbis is really small, only a couple things needed to be changed to fix all deadlocks with mp3s and such.) after that, i move on to the next item in my "todo" list that i posted. So what's everyone else up to besides rottmann making the finishing details of the build system so we can actually install zinf. at least i hope someone is. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf