Hi Matt, Sorry, I think you got me wrong, I wasn't actually volunteering or even wanting to add more work to do for myself. =) I was just curious to know if what everyone thought on the issue and if it they thought it was a real place for optimization, if anyone's already done something like this, if they thought it would or wouldn't be negligible, etc. Do any hosts currently implement setting their own message callbacks to work in an asynchronous manner? I know in blue that it reads from the console output for csound in an asynchronous manner (it was pretty painful and still causes problems on occasions) by having a separate reader thread for that, but that's using csound as an external process and not through the host API. It seems to work out fine in blue, but I don't know if more should/could be done. I don't know if other situations, say if Csound is embedded in a python host application, if special care is needed in reading the csound output to make sure it's done in a threaded way or that it'll slow down the kperf loop if a good message callback system isn't used. So, any thoughts/recommendations/etc.? steven On 10/28/06, matt ingalls wrote: > i assume you are talking about the commandline > and i would say fine, but let API hosts do their own buffering. > > On Oct 28, 2006, at 1:37 AM, Steven Yi wrote: > > > Hi All, > > > > I had a thought this morning for a possible optimization. It's an > > idea that I first came across in the Java world, which is to use a > > threaded logger to do all messages. The reason for this is that IO is > > generally expensive (or at least can be if writing out to console), so > > instead of directly writing out messages get posted to the logger > > which is running in it's own thread, so that in Csound, it can post > > the message and then get back to doing it's audio processing. > > > > I noticed with the new parser which has a *lot* of messages currently > > that it can take a while to get to the point where csound actually > > runs, but if I pipe the output to disk instead of console, it's really > > take only a very small fraction of that time. I think if it was > > threaded, it might get the same advantage in time. > > > > Any thoughts? > > steven > > > > ---------------------------------------------------------------------- > > --- > > Using Tomcat but need to do more? Need to support web services, > > security? > > Get stuff done quickly with pre-integrated technology to make your > > job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel? > > cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net