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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
