[MacRuby-devel] requesting advice for using Garbage Collection for a Cocoa MIDI app (so that I may use MacRuby)

Tom Jordan viresh53 at gmail.com
Wed Jul 27 22:53:23 PDT 2011


Hi, thanks for the reply Rob..   I just joined the list and was in digest
mode.. i hope this will reply to the already begun thread by just including
the same subject line.. if not, my apologies for beginning a duplicate
thread..

thanks for the advice.. that article looks familiar.. i think I saw it
before.. it may have planted a seed of doubt !
some good news.. I just saw that the Elysium MIDI sequencer app on GitHub
uses Objective-C with garbage collection, and it seems to work..

I was thinking that perhaps there may be a way to run some threads
separately "outside" of the garbage collection, so that if there is ever a
mark-and-sweep process going on, it would ignore the non-gc threads that may
be playing MIDI..  but it seems that registering any POSIX threads with the
GC with "objc_registerThreadWithCollector()" suggests otherwise (that there
is no way to use any non-GC threads in GC application).

If the app is being built with GC supported but not required, then it still
allows conventional allocation/retain/release methods of manual memory
management in some places..  this seems that there would be some way to
specify that certain threads are to not be affected by any GC operations..
I hope that is the case...   in any event, those threads obviously couldn't
use any MacRuby code..  so I guess this has fallen off-topic !

If anyone has any further info on this, it would be very helpful.. Thanks !


Cheers,

Tom


I have no expert weigh-in but only a quick google search revealed:

From: http://www.cocoadev.com/index.pl?GarbageCollection

>* The big cost is to latency - the ability of a program to respond near-instantaneously to real-time situations. For many programs, this is not an issue - nanosecond latency is simply not needed. Other problem domains cannot use mark-and-sweep for this reason, for example music (eg MIDI) programs. Low latency is impossible because during the mark-and-sweep process, the program cannot respond to external stimulus, so latency cannot be lower than the length of a mark-and-sweep.*
Maybe someone is kind enough to correct me.

Regards,
- Rob


On 2011-07-27, at 7:54 PM, Tom Jordan wrote:

>* Hi,*>* *>*     I'd like to use MacRuby alongside Objective-C in a MIDI app I'm writing.  I have already had success with evaluating MacRuby files from the AppDelegate and they work great in tandem with the rest of the code in Objective-C.   I'm just concerned about getting further along with application, and all of a sudden finding out that there are MIDI timing issues that are being adversely affected by the garbage collection.  Right now the MIDI output that the app is generating sounds tight, although the app is simple at this point, and I'm worried that as more objects get allocated, etc.. there may be some timing issues.  If that does happen, will there be a way to fix that using NSThreads?  Or would I need to use pthreads and register them with  "objc_registerThreadWithCollector()" ?    The reason I'm asking, is that I've tried to use an open-source MIDI framework that uses pthreads, and it will only work if GC is turned off.  I've tried to call "objc_registerThreadWithCollector()" from that code, but it's still not working.  At this point, I don't need to use the open source MIDI framework since I have MIDI working anyways.. but I'm concerned about timing issues creeping in later..  *>* *>* any advice is welcome...  If someone says "Your crazy for trying to write a MIDI application using Garbage Collection", or "Don't worry, Garbage Collection won't be a problem"... that will help immensely.. or something in between if that's the case.. any more knowledge on this subject will be greatly appreciated.. Thanks !*>* *>* Cheers,*>* *>* Tom Jordan*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20110728/ecb1ddcd/attachment-0001.html>


More information about the MacRuby-devel mailing list