Objective-C and runtime type inspection

[Mats Cronqvist]

Bob Ippolito wrote:
> On 8/17/06, Joel Reymont <joelr1@REDACTED> wrote:
>>
>> On Aug 17, 2006, at 8:38 PM, Bob Ippolito wrote:
>>
>> > The networking overhead is going to be irrelevant for the most part.
>> > None of the messages in a typical Cocoa app are big unless they're
>> > creating NSBitmapImageRep from memory or something. I'd make it a
>> > C-node personally.
>>
>> Ok, I'll go with that. It can be made a driver later on, if needed.
>> Question, though...
>>[...]
> On the other hand there's probably more fundamental problems to doing
> it with a driver, because you need to really do a lot of messaging
> from the main thread, and also the Erlang runtime really shouldn't be
> doing much in the main thread because that's going to be controlled by
> the NSRunLoop. I think it would be very difficult to write a driver
> that works correctly and doesn't screw up Erlang, but a c-node
> shouldn't have those sorts of issues.


   joel, were you seriously considering running your own event loop in a vm 
thread? if you can pull that off you'll have my eternal admiration. or something.
   otoh, implementing a c-node on top of the gtk main loop was dead easy.

   my reasoning for choosing a c-node over a port program was that the potential 
gain of using pipes instead of erlang distribution is small, since the app is 
likely to spend only a small fraction of it's cpu time in message passing. e.g. 
if the app spends 10% of it's time in the TCP stack, and pipes are infinitely 
fast, you'd still only gain 10% overall. plus i don't think the difference 
between the loopback and pipes are that big.
   of course, i dislike pipes on general principles, because distribution is 
what erlang is all about :>

   in gtkNode the messages from the erlang node is a list of {command,Args} 
tuples (so you can send a few big messages rather than many small ones).

   mats