Re: run NSApllication in an other thread

[Fred Kiefer]

Julien Isorce wrote:
> Hi,
> 
> I can read in NSApplication's documentation that it must be called in
> the main thread.
> 
> I am in a case where there is an other main loop (in C) that I cannot
> managed.
> The code I can access is an interface and its implementation that leads
> to a shared library loaded by the main application where there is this C
> main loop.
> Well, in the implementation (that I have to make) threre is 3 functions.
> One for initialization, one for deinitialization, and the last one is
> called periodically.
> In the init function I create an NSWindow. Then this window has to be
> updated in the function called periodically.
> 
> In no cocoa env I usually create a thread in the init function. This
> thread runs the specific window main loop (X loop or gdi32 loop). And it
> works pretty good.
> I want to do the same thing in a cocoa env. I mean, i would like to run
> the cocoa main loop in a thread created in the init function.
> 
> Even if I read that NSApplicationMain (or [NSApp run] ) must be called
> in the main thread, I  tried to call it in a different thread.
> But I am getting an acces violation in the main thread.
> Then if a replace the [NSApp run] from the second thread, by a while an
> a sleep,  I have an access violation in the main thread only I do not
> call [NSApp run] in the main thread.
> (but I cannot call [NSApp run] in the main thread because the function
> must be called periodically, I must not block the main thread)
> 
> I am creating the thread with:
> 
>  [NSThread detachNewThreadSelector: @selector(start:)
>         toTarget: [AppThread class]
>         withObject: nil];
> 
> (like I could see in the gnu step examples)
> 
> I am still on win32.
> 

Having two main loops is tricky, if not impossible. I would be far
better to have the two different mechanisms work on top of just one run
loop. Could you post your code to see whether this would be possible?

But as long as the real main thread doesn't make any Objective-C calls
you should be fine by running GNUstep in a secondary thread. In gui
there may be a few missing lock statements on the event queue handling
but the rest should be fine. What is unclear to me is how to stop
GNUstep base from listening to window events? Perhaps it is sufficent
not to call setupRunLoopInputSourcesForMode: in the backend? It surely
will require some fiddling with GNUstep internals, but it could be
workable. But are you sure this is where you want to go to?

Fred