> There are several things you could mean by this, but I'm guessing you mean a > set of thread-safe PMCs, that can be shared across threads. It's a > possibility.
I purposefully left this vague, there are really too many options to enumerate. Thread-safe PMCs (thread-safe queue, etc) would be nice. Also fitting into this category would be e.g. a Mutex PMC or a family of locking PMCs. A "Select" PMC to divvy out IO requests would work well with a Semaphore type, for instance. In any case, there would likely be several PMC types we would need to add to support the kinds of mechanisms people are going to want. > Make a list of the features Chandon needs (not wishlist, but absolute > essentials for his GSoC project), and we'll make sure they work. Though, > does he really even need shared variables for his project? The idea was to > prototype a new style of threading, the GSoC project doesn't require him to > drop it in as a whole replacement for the current implementation. Chandon's project is going well, his only blocker is the surprisingly broken (and under-tested) state of the scheduler, which he's picking apart and putting back together. At the end of his project, I have no doubt that we will have a working threading model of some variety. What we won't have is any way to safely share PMCs between threads, so any tests or demonstrations he does will probably need to explicitly avoid those situations. We will have threads, but I think they will be considered "unusable" in the practical sense if we can't serialize access to shared PMCs. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
