Re: [Pyobjc-dev] Achieving 1.0....

[Bill B. <bb...@co...>]

On Monday, October 28, 2002, at 04:00 AM, Ronald Oussoren wrote:
> All,
>
> I just remembered one implementation issue that should be worked on 
> before reaching a 1.0 release: Thread safety.

Agreed.

> The current code is probably save for multi-threading, but I haven't 
> really checked this. Basicly I removed all static/global buffers while 
> working on the code.
>
> There are some more issues:
> 1. Python has a global interpreter lock. When one thread owns this 
> lock, no
>    other thread can execute python code. The bridge currently never 
> gives up
>    the GIL when moving into native code and we probably should. I have 
> not yet
>    researched what we should do with callbacks from Objective-C to 
> Python.
>
>    E.g. the NSApplicationMain wrapper should release the GIL before 
> calling
>    the actuall function, but how do you regain the GIL during calls to 
> methods
>    implemented in Python?
>
>    This is necessary to avoid unecessary blockage of Python threads 
> during
>    calls to Objective-C code.

I believe Jack covered this, but wanted to add a couple of Obj-C and 
NS* specific bits of information:

As of OS X, NSThreads are actually built on top of pthreads and it 
should be possible to use Jack's code directly.  From the documentation:

...
NSThreads are built upon POSIX threads (pthreads). You can create your 
own pthreads, but some Cocoa classes, such as NSAutoreleasePool, expect 
to be running within an NSThread and may not work properly in a 
pthread. Creating a pthread does not notify Cocoa classes that the 
application has become multithreaded, so the NSThread method 
isMultiThreaded may return NO. If you need access to the pthread within 
an NSThread, call the pthread_self function from within that thread.
...

I would still recommend using the NSThread based API to create threads 
if the goal is to multi-thread an app that mixes Python and Obj-C in 
threads (for an app that uses pure-python in the threads, there is no 
need) because this is the only way that the ObjC runtime is going to 
become "thread aware".  Specifically, see the documentation on these 
notifications:

FOUNDATION_EXPORT NSString * const 
NSWillBecomeMultiThreadedNotification;
FOUNDATION_EXPORT NSString * const 
NSDidBecomeSingleThreadedNotification;
FOUNDATION_EXPORT NSString * const NSThreadWillExitNotification;

However, once the NSThread is created, the pthreads API can be used to 
store state and otherwise manipulate the thread -- the NSThread API is 
just the glue to make sure the ObjC runtime has the opportunity to deal 
w/the appropriate notifications.

If desired, NSThread provides for storage of per-thread state in a 
mutable dictionary.  Simply invoke -threadDictionary while executing in 
the thread that wants to store/retrieve the state.

When traversing from Python into Obj-C in a thread that was created in 
pure python (i.e. is just a pthread, does not have an NSThread 
instance), invoking NSThread's +currentThread method will return an 
NSThread that encapsulates the already created pthread.   I would 
assume that threaded python already has the pthread initialized with 
the appropriate state and it would just be a matter of adding any 
bridge specific state at this point?

It sounds like the harder problem is when the developer crosses from 
ObjC -> Python in a thread that was not created in Python and, 
therefore, the interpreter has not initialized the pthread state in the 
specific context of Python?

Note that as of 10.2, NSThread offers these two *extremely* handy 
methods:

- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg 
waitUntilDone:(BOOL)wait modes:(NSArray *)array;
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg 
waitUntilDone:(BOOL)wait;

b.bum