I'm not talking about blocking I/O. I'm talking about Mutexes that are used in critical sections for shared resources. Sorry, I guess I should have said Locking.
The problem is, when the mutex goes to wait, we have no guarantee that the scheduler will come back to us within the window of time needed to process(). I believe this is generally due to the multi-threaded rendering code in LMMS. There are other areas where we lock to get at some other data, data that could be copied instead. I would like to see if someone could improve this situation. I tried for a while and now I am working on the fresh-start strategy. -Paul On Fri, Mar 26, 2010 at 10:10 AM, Jonathan Aquilina <[email protected]> wrote: > im no programming expert and from the little that has been discussed in my > java programming class instead of using blocking I/o wouldnt it bet better > to uses non blocking I/o or does that not exist in c++? > > On Fri, Mar 26, 2010 at 2:55 PM, Paul Giblock <[email protected]> wrote: >> >> The main problem you will have to conquer is the fact that LMMS uses a >> lot of non-RT-safe code in what would have to be the process() thread. >> Between things like mallocs and blocking, there would be a whole lot >> to refactor to get proper JACK support. Also, there would be a great >> deal of work to make LMMS actually use JACK for it's routing (I.e: to >> wire a FX line to the Master line). >> >> Feel free to try this. People really want JACK support in LMMS. In >> the meantime, I'm going to keep working on my core rewrite. >> >> -Paul >> >> On Thu, Mar 25, 2010 at 7:01 PM, Filipe Lopes <[email protected]> wrote: >> > Hi there guys, thanks for this amazing app! >> > >> > I know you guys aren't too much interested in Jack support, so I think I >> > can >> > help with that. >> > But first, I need to know if there's anyone already working on this. >> > Also, some tips would be really useful, as I'm mostly a PyQy dev, not >> > C++. >> > >> > Here's a small vid showing what I was able to do so far >> > (play/pause/stop): >> > http://kxstudio.sourceforge.net/downloads/lmms-trans_exp01.ogv >> > (please download the file instead of open it, or it won't work). >> > >> > Thanks in advance >> > >> > >> > ------------------------------------------------------------------------------ >> > Download Intel® Parallel Studio Eval >> > Try the new software tools for yourself. Speed compiling, find bugs >> > proactively, and fine-tune applications for parallel performance. >> > See why Intel Parallel Studio got high marks during beta. >> > http://p.sf.net/sfu/intel-sw-dev >> > _______________________________________________ >> > LMMS-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/lmms-devel >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> LMMS-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/lmms-devel > > > > -- > Jonathan Aquilina > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
