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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.