[Openmcl-devel] Cocoa and other OS interfaces from OpenMCL

[Gary Byers]

On Wed, 3 Nov 2004, John Wiseman wrote:

> I want to play around with Rendezvous in OpenMCL, but even after
> reading a book or two on Cocoa I still feel like I'm in unfamiliar
> territory.  Like, I don't even know if I should program to the Core
> Foundation API or the Cocoa API.

Brendan Burns was doing some stuff that used Rendezvous via Cocoa
about 1-1/2 years ago:

<http://clozure.com/mailman/htdig/openmcl-devel/2003-June/001166.html>

His code was written for an older (pre native-threads) OpenMCL and
the ObjC interface has changed some since then, but his followup
message indicated that he got that code working (and that the
solution was simpler than I'd thought it would be ...)

>
> My experiments with the Cocoa API have so far only been partially
> successful--I think I need to create a NSRunLoop, but when I run it it
> seems to get stuck.

I think that telling an NSRunLoop to run (or doing the equivalent
thing to a CFRunloop) basically causes it to block until something
attached to the runloop (a timer or message port or something
similar); in some cases.  I'm pretty sure that getting stuck (blocking
forever) is what -should- happen if you try to run a runloop that
has no event sources attached to it.

As far as the relationship between runloops and NSNetService instance
goes: note that (although you can create your own runloop if you
really want to) each thread has its own default runloop object.  My
hunch/partial recollection is that the NSNetService that you create
gets automatically attached to the current thread's runloop, and that
methods in the service's delegate object get called whenever anything
interesting happens (without your having to worry too much about
network protocol details).

If the current thread is a listener running a read-eval-print loop,
that runloop isn't ordinarily running.  If you're running some variant
of the Cocoa GUI stuff, the initial thread is always running its
runloop (which is used for event handling).  Back in the days of
Brendan's message, all lisp threads (cooperatively) shared an
underlying native thread (and therefore shared a default runloop),
so he could just tell the net service he'd created to publish itself
from any lisp thread and it'd be connected to the global, shared
runloop; nowadays, it'd be necesary to do someting like:

(send (objc-net-service service)
      :perform-selector-on-main-thread (@selector "publish")
      :with-object (%null-ptr)
      :wait-until-done nil) ;; or wait, if you'd prefer

to ensure that the service is is connected to the main (event-handling)
thread's runloop.  (You could also use PROCESS-RUN-FUNCTION or the
like to create a thread, have the service publish itself in that thread,
and then run the thread's default runloop to handle connections (or
UDP broadcasts, or whatever the gory underlying details involve.)

>
> Can anyone describe why one might choose between Core Foundation and
> Cocoa in the context of interfacing from OpenMCL?
>

There are a log of Cocoa classes (NS*) that are pretty thin wrappers
around equivalent Core Foundation (CF*) objects.  (In several cases,
the wrapper's so thin as to be invisible: some CF objects are also
NSObjects).

In the case of NSRunLoop objects, Cocoa provides a slightly higher-level
wrapper around an underlying CFRunLoop object and an accessor method
("getCFRunLoop") that allows you to get your hands on the CFRunLoop
and do lower-level things.  I'd agree with Mikel's observation that
the NS layer is usually higher level than the CF layer and it therefore
makes sense to work in that higher level where practical.

(There may be other case where the NS class is pretty clearly a thin
wrapper around a CF class or other lower-level functionality and
there's no way to get your hands on the lower-level object, but there
are certainly lots of cases where you can effectively use both NS
and CF objects simultaneously.)

I think that you'd also find that CF is already somewhat higher-level
(and more Cocoa-like) than a lot of traditional C APIs.

>
> Thanks,
> John
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>