> Imo waste of time, I know some of the code and (see condition.C) it > might be evolved due workaround problems in early linuxthread > implementations but it is horribly ugly and broken by design. In a > experimental branch I started to add my 'NoBug' library with a > resource/deadlock checker to cinelerra which shown a few too. But > finding this races is really the simplest thing. Fixing them is a really > hard design issue, I won't say it is impossible but it is certainly not > simple and very intrusive. I started to write more bullet proof locking > classes for cin2 just to find out that going over the code and > refactoring/adding that was more complicated than I imagined. Actually > the locking problems in cinelerra are one of the main issues I proprosed > cin3 as new rewrite. If you have the patience and want to make some > efforts to fix it, that would be a major contribution to cinelerras > stability and performance, but for myself I dont wan't to touch that > code anymore currently. > > Christian
Christian, OK. Its understandable that you'd want to work on new, more resilient software. My C chops aren't that strong and I'm working on some other projects right now. I might continue sending some debug streams to bugs.cinelerra, just in case someone else has the inclination to work on this issue.. scott _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
