[Mono-osx] There Bool Dragons Here

[Allan Hsu]

On Dec 16, 2006, at 3:53 PM, R. Tyler Ballance wrote:

> This is a Dumbarton related question, there will surely be many to  
> follow :)
>
> 1)
> I'm curious as to how "safe" DB_BOX_BOOLEAN is, from my  
> understanding with p/invoke code, booleans are tricky as they tend  
> to be represented differently on a variety of different  
> architectures, should I write my wrapper code using int values of   
> 0, and -1, or can I safely rely on bool to not "screw things up  
> royally down the line"

It should work fine as long as you're treating your booleans as BOOL  
types in ObjC. Mono's booleans are of type "MonoBoolean", which are  
just typedef'd unsigned chars. The BOOL type in ObjC is a signed  
char, but I think that any sane thing you do should work with the  
standard C "zero or not zero" boolean logic.

> 2)
> From the best of my understanding there's no way to have events  
> traverse into notifications of some sort on the other side of the  
> bridge, and I'm wondering what other 'notification' methods might  
> be possible, such as calling function pointers (i.e. how async I/O  
> in C can be achieved), etc. I'm going to have a few threads running  
> in the C# core that would need to notify the native Cocoa UI  
> through some means when things long extended (non-blocking) network  
> I/O calls are finished. Suggestions?

There *should be* (but isn't) a simple way to do this by doing some  
C# event bridging magic in Dumbarton. The current solution that we  
use at imeem is to register internal calls for event-firing functions  
that can be called from C#. The implementing code on the non-managed  
side then takes the arguments to the event and packages them into an  
NSNotification, which gets queued asynchronously onto the main thread  
through an NSNotificationCenter. From that point, ObjC code just  
observes the notification like any other Cocoa-style notification. It  
would probably be possible to write code in Dumbarton to emit code at  
runtime that allowed you to subscribe a dynamically generated managed  
wrapper delegate to a C# event, but I don't have the time to look  
into this, and nobody else has needed anything like this...:)

> 3)
> Memory management (insert pause here to allow cringing where  
> appropriate). While Objective-C 2.0 may have garbage collection, am  
> "I responsible" for taking care of my DBMonoObjectRepresentation  
> subclasses in terms of releasing them where appropriate, and then  
> just let the C# code garbage collect as per usual in wholesale Mono  
> applications? Are there any caveats to "standard" memory management  
> with Cocoa that I should be aware of before I unleash memory leaks  
> a'plenty upon my code base? ;)

As long as you properly retain/release your wrapper objects, you  
should be fine. A leaked ObjC wrapper object means the underlying C#  
object is also leaked. If, for some reason, you keep around unwrapped  
C# object references in ivars, you'll need to either register gcroots  
or create a GC handle for those objects or they will be collected out  
from under you.

There are no guarantees that ObjC-2.0 garbage collection will be  
possible with Dumbarton. The interaction between the two garbage  
collectors will be... interesting. It may be possible, but maybe not.  
Another thing to worry about is that if the two GCs play nicely with  
each other, you now have two different GCs routinely suspending your  
threads and walking their stacks... not exactly a formula for good  
interactivity. I talked to one of the creators of the new GC at WWDC  
and it looks like it might be possible to make Mono use the new GC  
instead of libgc or sgen (with some caveats), but I haven't tried  
actually doing this with the 10.5 DP.

[...]
> I really can't thank you imeem guys enough for Dumbarton, this  
> project I'm working on right now involves:
> 	- Custom network libraries implemented in C
> 	- C# core with sporadic calls out to platform dependent code
> 	- native Cocoa interface with plenty of pretty AppKit subclasses
>
> Without Dumbarton, tying all this together would fall under the  
> "clusterfuck" umbrella, where it stands now, it's just in the  
> "wtf?" camp :)

It's good to see other people are getting use out of Dumbarton.

	-Allan

--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779