I think that renodino's idea of a separate api for setting the default stacksize is a good one. I'd store the value into the PerlIterpreter struct (interp.h) with a default value similar to the current stacksize setting for compatibility. Once altered, and new threads would inherit the new size. If it gets reset in a spawned thread, any threads spawned from that thread would inherit the new value.

That does mean your separate package would have a dependancy upon the addition of that new field to the core, but I don't see why that would be a show stopper.

I'd also add an extended threads->create() method, (maybe threads->createEx() if that's not 'too MS'?), that took a hashref as the first parameter and the standard args thereafter. The contents of the hashref would be a set of (potentially platform specific), named args that would be passed either directly or in modified form to the CreateThread()/pthreads_create() calls. If the hashref was empty (or undef is passed) then it maps to the normal create() method.

The keynames could be mapped to the standard parameter names used by the platform api docs, giving you a pretty extensible api that would allow for future expansion if the need arises. For example, I could see the possibility of passing a SECURITY_ATTRIBUTES structure being a useful facility.

While you're there :), could you also add an instance method for accessing the native thread handle from the Perl thread object $threadObject->getNative()?

That would facilitate using platform specific apis (like SetThreadPriority(), suspend/resumeThread(), pthreads_suspend_np() etc.), from add-on packages without requiring the main threads package to support everything for all platforms.