in reply to Re: Missing (i)threads Features?
in thread Missing (i)threads Features?
I agree.
...There is also a scheme for dynamically boosting a threads priority for short periods...
Periods determined by what? Time? An event? (Un)Availability of a resource?
...yield actually yields, it would be better if yield where implemented to do something sensible--like sleep for short periods--
Hmmm... that's easily done if you're able to determine reliably that yield() is a no-op on your platform.
...create threads and suspend them pending some event...
You could do something like that on Linux with Thread::Signal by creating a signal handler that, when called, will block on a variable, and another signal handler that resets that variable. Hmmm... I feel a module coming up... ;-)
...The situation is the 'pool of threads' scenario where you want to have the main thread block until one of the current threads has finished.
I'm not sure what you mean, but are you sure this cannot be handled with Thread::Pool or Thread::Queue::Monitored or Thread::Conveyor::Monitored ?
A minor critique of your current implementation of Thread::Running etc. is that I have to supply a list of threads to be checked
That was the case in 0.01 ;-). In 0.02, the default for running(), tojoin() and exited() are all of the threads that Thread::Running knows about. Please RTFM ;-).
Debugger support for threads needs improvement.
I agree. I've created two debugging support modules for threads. Thread::Status which shows you where each thread is at a given time (unfortunately, only on Linux because of dependency on Thread::Signal) and Thread::Deadlock which will tell you where threads are when a deadlock occurs.
...view source around the current point on a thread by thread basis...
I could add this as an option to Thread::Status.
...die ,warn and Carp should all include the thread id in their output by default in threaded applications.
I actually submitted a patch for this before 5.8.0. The problem is that many tests depend on the format of die, warn and Carp, and it was breaking all sorts of tests ;-( At least, that's how I remember it (a lot has happened since). But I agree, yes!
Most of this stuff would be better, more easily and more efficiently done in threads.xs rather than requiring several extra modules each with its own state which (often) duplicates state already existing at the system level. Perhaps the powers that be would accept a threads::util module for this sort of stuff.
Patches welcome ;-). But not for 5.8.1, I'm afraid. Jarkko would go ballistic if anyone would start submitting patches for threads related stuff for inclusion in 5.8.1... ;-)
To date, I still haven't succeeded in building perl with a free compiler such that it isn't emasculated (no large file support or PerlIO for example).
??? on what system?
Liz