[Dev] Mac recursion limit?

[Andi Vajda]

> Interestingly, on Mac OS X (10.3.8), the pthread_stacksize_np() call returns 
> 512K as the size of both the main and background threads. However, threads 
> created by Cocoa APIs (the NSThread class) are only 188K.
>
> How are Chandler's various threads being created?

Chandler threads can be created in two ways:
   - normal python threads: on OS X and Linux, these are pthreads.
   - PyLucene threads: on OS X and Linux, these are pthreads created and
     initialized by libgcj and then passed to python for its own awareness.
     (See class PythonThread in PyLucene.i)

PyLucene threads are needed for all the threads that need to access PyLucene 
(and libgcj), that is, any thread that uses the repository since during 
commit, PyLucene may be accessed for indexing, or, once we start using it 
more, during queries.

The PyLucene thread trick is new (from December). The feedparser.py bug is 
not. It happened before, in the same way, was fixed, patched. The patch was 
sent to the author but from then on, the fix was lost again. Now, it got fixed 
again by Grant and Phillip. The actual feedparser.py bug is a bug on all 
platforms but only crashes on the Mac. The stack is blown in the 
feedparser.py and that error is masked by some over-eager exception catching.

Still, preventing stack crashes on the Mac would be progress, no doubt.

Andi..

>
> --Grant
>
> On Mar 1, 2005, at 10:29 AM, Phillip J. Eby wrote:
>
>> At 10:00 AM 3/1/05 -0800, Alec Flett wrote:
>>> Hey Phillip - I just tried this on mac without the modifications you 
>>> describe:
>>> recurse
>>> add
>>> repr
>>> init
>>> getattr
>>> getitem
>>> Limit of 4900 is fine
>>> recurse
>>> add
>>> Segmentation fault
>>> 
>>> seems pretty high!
>> 
>> The default of 1000 is generally conservative.  But the crash associated 
>> with bug 2563 was fewer than 500 levels, so non-main threads are apparently 
>> quite tight.
>> 
>> 
>>> I'll try it with threads later today or tomorrow if I get a chance... 
>>> also, I wonder how deep it can go if there are lots of local variables in 
>>> use?
>> 
>> Local variables are stored in frame objects that are heap-allocated, so it 
>> shouldn't make a difference.  Only local variables of C functions (not 
>> Python ones) count towards the stack usage.
>> 
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> 
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>