> =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?
Yes.
>Could you elaborate on the nature of what would constitute a "ping"?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)
POSIX has a function cond_signal (and cond_broadcast, which is similar). What happens is a thread grabs the condition variable and goes to sleep, and sleeps until another thread does a cond_signal, which then wakes it up. If there are multiple threads sleeping on the condition variable, only one is woken. (cond_broadcast wakes them all up)
> =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:)
No problem. It's the model I prefer. :)
> =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?
Yeah. On Win32, when Perl forks it starts a new thread and clones the interpreter and its contents. If you later do an exec in that thread it starts a new process and grabs hold of it. Definitely a clever trick.
An interesting extract from the Windows Services for Unix docs.
"The Interix subsystem shows improvements in all aspects of performanceranging 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).
If it works, cool. We can add environment probing at configure time. I worry some about the stability and evil involved there (I've a good idea how much work it is to weld fork into a process with a fundamentally different process model) but that's Microsoft's problem, not ours.
> =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
We'll generally hide behind the memory.c routines, if for no other reason than to allow the embedder to override the memory functions. We need to define that at some point...
>=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.
TIDs, definitely. It'll be a sysinfo or interpinfo function. There's the issue of interpreters binding to different threads, but we'll deal with that. I'm not sure what the HANDLE is, but explain it and we can work something out. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
