develooper Front page | perl.perl5.porters | Postings from November 1999

Re: [PATCH 5.005_62]Allow XS code to lock arbitrary scalars

Thread Previous | Thread Next
Dan Sugalski
November 16, 1999 09:32
Re: [PATCH 5.005_62]Allow XS code to lock arbitrary scalars
Message ID:
I can change the macro/function name and its implementation easily enough,
that's not a problem. This, though:

>All that said, every time I see people patching USE_THREADS code I
>wonder if it's all going to be for nothing.  I don't see much hope
>for salvaging the existing model of USE_THREADS where prolific
>locking is needed.

Can we get a ruling on whether threads as they stand are in or out? And a
statement of direction if they're in?

I really don't mind writing code that ultimately gets tossed out because it
sucks or there's a better way to do things--it's a learning experience if
nothing else, and the next time around the code's usually better. What I
don't want to bother doing is writing code that is going to be tossed
because I'm going the wrong way.

I mean, at this point I've got code for Thread::Stop roughed out,
preliminary mutex tracking set, and a scheme to make unsynchronized scalar
access safe with about an order of magnitude less overhead than my last
try. Getting them all going is a good chunk of work, and I don't mind doing
it. I think it needs to be done, and that's not the point. I have other
things to occupy my time, though, and I'd just as soon not tilt at these
windmills without cause.

If the current threading model is dead, can we just shoot the poor thing
and be done with it? Otherwise let's commit to it and figure out what needs
to be done. This limbo state isn't doing anyone any good.


----------------------------------------"it's like this"-------------------
Dan Sugalski                            even samurai                           have teddy bears and even
                                        teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About