Re: Re: Re: Re: Missing (i)threads Features? (Some more ranting:)

[liz]

...that event has a higher (but not exclusive) chance of being selected as the next thread to be run by the scheduler. The threads priority returns to its unboosted level the next time it is run.

Makes sense. Seems like a nice feature to have (and be able to support from Perl).

...if that alternative was provided by the threads module by default rather than requiring an extra piece of code that every user...

I agree. But I'm trying to do the next best thing, namely doing it in such a way that _if_ it would get fixed in the threads module in the future, my Thread::xxx modules would effectively become no-ops.

The problem with that is that it won't work on platforms that don't support signals.

If we could get something similar going on those other platforms, that would fine also. Fake signal delivery on Win32 ;-).

t is also adding layers on top of the threads API in a way that makes it difficult to code cross-platform. The extra layers also make for very complicated debugging.

If it were possible another way, I would be for that. But debugging threaded applications is complicated anyway. A Heisenbug is very easily made.

In this case, on Win32, SuspendThread and ResumeThread translate directly to native APIs. Then only thing missing is access to the native thread handle.

But do SuspendThread and ResumeThread know about Perl? There's SIGSTOP and SIGCONT on *nix, but I didn't use that for Thread::Suspend because I was afraid that Perl would get stuck somewhere in the middle of something vital.

It's actually quite easy to obtain this handle as there is a native API that will return a usable handle for the currently running thread, which may or may not be the same as the native handle stored within the threads module.

Would this value somehow be shareable?

The problem comes to trying to devine what effect using this to suspend a thread externally to the threads module will have upon the perls management of that thread? Maybe if the thread is suspended, nothing untoward will happen, but maybe Perl will take umbrage at having one of it's threads rendered un-runnable without it being consulted:)

Indeed. That's why I'm not using SIGSTOP and SIGCONT on *nix.

With regard to your many Thread::* modules. The problem (from my Win32 platform perspective) is that many of them rely entirely upon platform-dependant idioms like Signals.

The only real platform dependent one (right now) is Thread::Signal. But the input to Thread::Signal->signal are a thread ID (which is also available with threads on Win32) and a string. Surely this should be portable to Win32 somehow?

I can see how to implement most, if not all of them on the Win32 platform, but not in a way that would make them compatible with the modules you have already written. This would make life very tough for anyone trying to utilise them for cross-platform development.

I actually think it would be much easier than we think. The most important thing is to get Thread::Signal (or something similar) going on a thread independent manner.

This is where trying to find a platform independant iThreads API set would be useful. If (we?) could take a step back from specific implementations and try and look at what features would be useful to have and try to encapsulate those features within an API that would enable them to implemented reasonably efficiently on all (or at least most) platforms, then it might be possible to come up with something that would be truely usable.

idea++

Perhaps the solution here is for the patch(es) to die ,warn and Carp to detect whether threads were being used and only use the modified form if they were?

That sounds easier than it is, I'm afraid ;-(

Rather than patching the existing threads module directly, I was thinking more of coming up with a single threads::util module that would have access to the internal structures (native thread handles etc.) that encapsulated all of the new APIs. Whether that was later adopted or integrated could be left for powers-that-be to decide later on.

One very important reason for me to make so many seperate modules, is that you can mix and match easily. And that's very important in the current Perl threads implementation, as all of the data-structures are copied between threads (and stashes are data-structures ;-).

...Win32. I tried MingW, Borland and LCC so far. I get furthest with Borland, but its STDIO libraries don't have huge file (>4GB) support.

Have you taken this up with p5p?

The biggest barrier to making changes to the perl build process is the incredibly conveluted and incestuous nature of the build mechanisms.

I think no one will disagree with that. Maximum portability comes at a price. Patches are welcome. You might want to contact H. Merijn Brand (configure pumpking and fellow Amsterdam PerlMonger) if you have questions about the build process. He is in currently streamlining the configure process.

I have had lots of time, and whilst my skill levels may not be upto the standards of those that precede me, I'm not exactly clueless. I've spent several months trying to get a handle on the while thing and still it defeats me.

Have you asked questions on p5p? There are a lot of people there that might be able to help you.

Step by step, this means that fewer and fewer people will ever be able to contribute to the perl codebase and leave more and more people dependant upon the time, skills and motivation of fewer and fewer experts. From my persepctive, this is tantamount to the death-knell for an open source project.

That is why things are being done differently for Parrot, Ponie and Perl6. That is more a community effort from the beginning as opposed to a personal project with community support bolted on afterwards.

...someone to discard the existing build process and start again. I've had 2 or 3 attempts at starting this process, but you need to be a computer to be able to resolve all the paths and inter-dependancies. Trying to unwind them is nearly impossible for a human being--at least it is for this human being. I'm afraid I've had to give up on that approach.

I think you really should contact H. Merijn Brand... ;-)

Please excuse any typos, but hopefully everything is understandable. Life is too short to pander to anal-retentive pedants who specialise in braying about the syntax instead of concentrating in the symantics.

No problem about that from my end ;-)

Liz

[BrowserUk]

We are taking further discussion of this elsewhere. If anyone is interested in following or contributing to the discussion, please contact one of us and we will include you.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.