> =item MUTEX > > This is a low level, under the hood, not exposed to users, thing that > can be locked. They're non-recursive, non-read/write, exclusive > things. When a thread gets a mutex, any other attempt to get that > mutex will block until the owning thread releases the mutex. The > platform-native lock construct will be used for this. > Will this be macroised to hide the platform native implementation from the main body of the code?
> > The "sleep until something pings me" construct. Useful for queue > construction. Not conceptually associated with a MUTEX. (POSIX > threads require this, so we're going to hide it there behind macros > and/or functions) > Could you elaborate on the nature of what would constitute a "ping"? > > =item POSIX threads > > The threading scheme must be sufficient to support a POSIX > share-everything style of threading, such as is used in perl 5's > "pthread" model, as well as the thread models for Ruby and Python. > Thankyou:) > > =item "Process-type' threads > > The scheme must also support the perl 5 "iThreads" threading > model. In this model no data is shared implicitly, and all sharing > must be done on purpose and explicitly. It very much resembles the > Unix fork-process-with-shared-memory-segment model, not a surprise as > it was originally developed with > Pseudo forks? An interesting extract from the Windows Services for Unix docs. "The Interix subsystem shows improvements in all aspects of performance—ranging from 30 percent improvements in fork and exec performance..." It's sales pitch, but I'm trying to verify it (and build parrot using it). > > > =item System memory allocation routines are threadsafe > > We are assuming that the memory allocation system of the base OS is > threadsafe. While some of the C runtime libraries are notoriously > thread dangerous, memory allocation code generally is threadsafe, and > we'll assume that on all platforms. (Though we will, in general, > manage our own memory) > Is there any likelyhood that memory allocation will be hidden behind macros at two levels: - ALLOCPOOL() for allocating large chunks of memory (ppols) that are later sub-allocated (and managed) by: - SUBALLOC() for sub allocating within a pool ? > > =item Each interpreter will have a unique id > > This ID will be independent of the process or OS thread, and will be > constant across the lifetime of the interpreter. Interpreter IDs > I<may> be reused as interpreters are destroyed and recreated, and as > such are only guaranteed valid while an interpreter is in use. > The provision of method(s) to obtain the native TIDs/HANDLES would make life for those writing implementation specific extensions easier. > >[SNIP] - Too much to understand before commenting... > > > --------------------------------------"it's like this"------------------- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk Nigel
