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

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

On Tuesday, October 29, 2002, at 07:16 AM, Jack Jansen wrote:
> On Tuesday, Oct 29, 2002, at 11:31 Europe/Amsterdam, Jack Jansen wrote:
>> On Monday, Oct 28, 2002, at 17:45 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> 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.
>>
>> If you do this, does that make a pthread a fullblown NSThread? I.e. 
>> does it make the problems you sketched earlier (such as 
>> isMultiThreaded returning NO) go away?
>
> To answer my own question: no, it doesn't. isMultiThreaded still 
> returns NO after this call.
> Is this a problem? If so, is there a way to tell NSThread that we 
> *are* multithreaded?

That would seem to be a bug that should be reported to 
bugreport.apple.com.  If you have a little hunk of test code, that 
typically accelerates Apple's bug fixing process considerably.

It sounds like you'll need to create a zero resources thread via 
NSThread:

[NSThread detachNewThreadSelector:@selector(intoTheVoid:) 
toTarget:[NSObject class] withObject: nil];

@implementation NSObject (TheVoid)
+ (void) intoTheVoid: aNothing
{
     l = [[NSLock alloc] init];
     [l lock];
     [l lock];
}
@end

This will effectively dead lock the thread in a fashion that should use 
zero CPU cycles (assuming NSLock is correctly implemented).  There is 
also no way to kill the thread -- export the NSLock and call [l unlock] 
once to do so.

Bogus.  Totally Bogus.  But should do the trick.

It is likely that we will need some similar bogosity in the PyObjC 
bridge.

b.bum