зеркало из https://github.com/mono/mail-archives.git
149 строки
6.9 KiB
HTML
149 строки
6.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [Mono-osx] There Bool Dragons Here
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="index.html" >
|
|
<LINK REL="made" HREF="mailto:mono-osx%40lists.ximian.com?Subject=%5BMono-osx%5D%20There%20Bool%20Dragons%20Here&In-Reply-To=210C6054-62AE-44F5-8E56-7B9DEF26F892%40bleepconsulting.com">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
<LINK REL="Previous" HREF="000714.html">
|
|
<LINK REL="Next" HREF="000717.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[Mono-osx] There Bool Dragons Here</H1>
|
|
<B>Allan Hsu</B>
|
|
<A HREF="mailto:mono-osx%40lists.ximian.com?Subject=%5BMono-osx%5D%20There%20Bool%20Dragons%20Here&In-Reply-To=210C6054-62AE-44F5-8E56-7B9DEF26F892%40bleepconsulting.com"
|
|
TITLE="[Mono-osx] There Bool Dragons Here">allan at counterpop.net
|
|
</A><BR>
|
|
<I>Sat Dec 16 20:05:34 EST 2006</I>
|
|
<P><UL>
|
|
<LI>Previous message: <A HREF="000714.html">[Mono-osx] There Bool Dragons Here
|
|
</A></li>
|
|
<LI>Next message: <A HREF="000717.html">[Mono-osx] Mono and Obstufcation on OSX
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#715">[ date ]</a>
|
|
<a href="thread.html#715">[ thread ]</a>
|
|
<a href="subject.html#715">[ subject ]</a>
|
|
<a href="author.html#715">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>
|
|
On Dec 16, 2006, at 3:53 PM, R. Tyler Ballance wrote:
|
|
|
|
><i> This is a Dumbarton related question, there will surely be many to
|
|
</I>><i> follow :)
|
|
</I>><i>
|
|
</I>><i> 1)
|
|
</I>><i> I'm curious as to how "safe" DB_BOX_BOOLEAN is, from my
|
|
</I>><i> understanding with p/invoke code, booleans are tricky as they tend
|
|
</I>><i> to be represented differently on a variety of different
|
|
</I>><i> architectures, should I write my wrapper code using int values of
|
|
</I>><i> 0, and -1, or can I safely rely on bool to not "screw things up
|
|
</I>><i> royally down the line"
|
|
</I>
|
|
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.
|
|
|
|
><i> 2)
|
|
</I>><i> From the best of my understanding there's no way to have events
|
|
</I>><i> traverse into notifications of some sort on the other side of the
|
|
</I>><i> bridge, and I'm wondering what other 'notification' methods might
|
|
</I>><i> be possible, such as calling function pointers (i.e. how async I/O
|
|
</I>><i> in C can be achieved), etc. I'm going to have a few threads running
|
|
</I>><i> in the C# core that would need to notify the native Cocoa UI
|
|
</I>><i> through some means when things long extended (non-blocking) network
|
|
</I>><i> I/O calls are finished. Suggestions?
|
|
</I>
|
|
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...:)
|
|
|
|
><i> 3)
|
|
</I>><i> Memory management (insert pause here to allow cringing where
|
|
</I>><i> appropriate). While Objective-C 2.0 may have garbage collection, am
|
|
</I>><i> "I responsible" for taking care of my DBMonoObjectRepresentation
|
|
</I>><i> subclasses in terms of releasing them where appropriate, and then
|
|
</I>><i> just let the C# code garbage collect as per usual in wholesale Mono
|
|
</I>><i> applications? Are there any caveats to "standard" memory management
|
|
</I>><i> with Cocoa that I should be aware of before I unleash memory leaks
|
|
</I>><i> a'plenty upon my code base? ;)
|
|
</I>
|
|
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> I really can't thank you imeem guys enough for Dumbarton, this
|
|
</I>><i> project I'm working on right now involves:
|
|
</I>><i> - Custom network libraries implemented in C
|
|
</I>><i> - C# core with sporadic calls out to platform dependent code
|
|
</I>><i> - native Cocoa interface with plenty of pretty AppKit subclasses
|
|
</I>><i>
|
|
</I>><i> Without Dumbarton, tying all this together would fall under the
|
|
</I>><i> "clusterfuck" umbrella, where it stands now, it's just in the
|
|
</I>><i> "wtf?" camp :)
|
|
</I>
|
|
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
|
|
|
|
|
|
</PRE>
|
|
|
|
|
|
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI>Previous message: <A HREF="000714.html">[Mono-osx] There Bool Dragons Here
|
|
</A></li>
|
|
<LI>Next message: <A HREF="000717.html">[Mono-osx] Mono and Obstufcation on OSX
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#715">[ date ]</a>
|
|
<a href="thread.html#715">[ thread ]</a>
|
|
<a href="subject.html#715">[ subject ]</a>
|
|
<a href="author.html#715">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
|
|
<hr>
|
|
<a href="http://lists.ximian.com/mailman/listinfo/mono-osx">More information about the Mono-osx
|
|
mailing list</a><br>
|
|
</body></html>
|