Not using "no strict 'refs'" in a Thread hangs perl

[p5pRT]

Migrated from rt.perl.org#1665 (status was 'resolved')

Searchable as RT1665$

[p5pRT]

From abisain@qualcomm.com

I have a module which spawns a thread using Thread.pm. The spawned thread uses a symbolic reference to call a function in "main​::". I have "use strict" at the top of the module. When I use this module in a script\, the thread containing the symbolic reference hangs without any error message. It hangs right at the point where I am using the symbolic reference. If I say "no strict 'refs'" before using the symbolic reference\, it works as expected.

So\, I think perl should print an error.

Also\, there should be a setPriority method in Thread.pm because a thread never gets a chance to run if the parent keeps using the CPU.

Perl Info

``` Site configuration information for perl 5.00551: Configured by jbarbour at Wed Sep 9 09:49:01 PDT 1998. Summary of my perl5 (5.0 patchlevel 5 subversion 51) configuration: Platform: osname=solaris, osvers=2.5.1, archname=sun4-solaris-thread uname='sunos ale 5.5.1 generic_103640-18 sun4u sparc sunw,ultra-4 ' hint=previous, useposix=true, d_sigaction=define usethreads=define useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-D_REENTRANT' ccflags ='-D_REENTRANT' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -R /pkg/perl5/5.005_51/lib/5.00551/sun4-solaris-thread/CORE' cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib' Locally applied patches: @INC for perl 5.00551: /pkg/perl5/5.005_51/lib/5.00551/sun4-solaris-thread /pkg/perl5/5.005_51/lib/5.00551 /pkg/perl5qc/lib/5.00551/sun4-solaris-thread /pkg/perl5qc/lib/5.00551 . Environment for perl 5.00551: HOME=/usr2/abisain LANG=C LD_LIBRARY_PATH=/usr/lib:/usr/ucblib:/usr/openwin/lib:/usr/dt/lib:/pkg/opnet-3.0a/3.5.A/sys/sun_sparc_solaris/lib:/afs/gv/2.0.1/sun4x_55/pkg/atria/v3.1.1/sun5/sun5/shlib:/local/mnt/workspace/abisain/ns-allinone-2.1b5/otcl-1.0a4 LOGDIR (unset) PATH=/pkg/perl5/5.005_51/bin:/usr/local/packages/SUNWspro5.0/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/afsws/bin:/usr/openwin/bin:/usr/dt/bin:/pkg/acrobat/3.0/bin:/pkg/gnu_compilers/bin:/pkg/xfig/bin:/pkg/opnet/6.0.L/sys/unix/bin:/pkg/tex/bin:/pkg/wts/bin:/pkg/emacs1928/bin:/pkg/rplay/bin:/pkg/mm/bin:/pkg/oracle/product/client/1.3.2/bin:/pkg/tcl/bin:/usr/local/bin:/usr2/abisain/bin:/pkg/atria/v3.1.1/sun5/sun5/bin:/usr/atria/bin:/pkg/gnu/bin:/pkg/java/jdk1.2/bin/:.:/pkg/acrobat/bin:/local/mnt/workspace/abisain/ns-allinone-2.1b5/bin:/usr2/abisain/bin:/pkg/atria/v3.1.1/sun5/sun5/bin:/usr/atria/bin:/pkg/gnu/bin:/pkg/java/jdk1.2/bin/:.:/pkg/acrobat/bin:/local/mnt/workspace/abisain/ns-allinone-2.1b5/bin PERL_BADLANG (unset) SHELL=/bin/tcsh ```

[p5pRT]

From [Unknown Contact. See original ticket]

At 03​:33 PM 10/19/99 -0700\, Abhijeet Bisain wrote​:

I have a module which spawns a thread using Thread.pm. The spawned thread uses a symbolic reference to call a function in "main​::". I have "use strict" at the top of the module. When I use this module in a script\, the thread containing the symbolic reference hangs without any error message. It hangs right at the point where I am using the symbolic reference. If I say "no strict 'refs'" before using the symbolic reference\, it works as expected.

Actually\, that's not quite the case\, or at least it's not supposed to be. The thread has died at that point\, but when a non-main thread throws an exception the exception is held until the thread is joined. This allows the program to catch errors in threads the same way that it catches the errors in subroutine calls.

So\, I think perl should print an error.

It will. The error will be thrown when you join the thread\, unless you eval the join to catch the error.

Also\, there should be a setPriority method in Thread.pm because a thread never gets a chance to run if the parent keeps using the CPU.

Then you've got a mildly deficient threading library. Perl threads will probably never have priorities--they're a touch high-level for that to be really safe. Your platform's threading library should parcel out CPU time to the various threads in your program as it sees fit.

  Dan

----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

Dan Sugalski writes​:

Actually\, that's not quite the case\, or at least it's not supposed to be. The thread has died at that point\, but when a non-main thread throws an exception the exception is held until the thread is joined. This allows the program to catch errors in threads the same way that it catches the errors in subroutine calls.

So\, I think perl should print an error.

It will. The error will be thrown when you join the thread\, unless you eval the join to catch the error.

Is not it a default that threads are joinable?

  a) as thread-conscious people know\, having threads joinable is a   very bad default;   b) if it is a default\, then the behaviour you describe is a bug.

By default errors in threads should be reported. In a rare situation when somebody consciously wants to join a thread\, she would declare this\, and *then* the behaviour you describe should make sense.

Then you've got a mildly deficient threading library. Perl threads will probably never have priorities--they're a touch high-level for that to be really safe. Your platform's threading library should parcel out CPU time to the various threads in your program as it sees fit.

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 11​:54 PM 10/19/99 -0400\, Ilya Zakharevich wrote​:

Dan Sugalski writes​:

Actually\, that's not quite the case\, or at least it's not supposed to be. The thread has died at that point\, but when a non-main thread throws an exception the exception is held until the thread is joined. This allows the program to catch errors in threads the same way that it catches the errors in subroutine calls.

So\, I think perl should print an error.

It will. The error will be thrown when you join the thread\, unless you eval the join to catch the error.

Is not it a default that threads are joinable?

It is the default that perl threads are created joinable\, yep.

a) as thread-conscious people know\, having threads joinable is a very bad default;

Debatable. Regerdless\, it's the way things are at the moment. And the current interface leaves no way to set the properties of a thread at create time.

b) if it is a default\, then the behaviour you describe is a bug.

By default errors in threads should be reported. In a rare situation when somebody consciously wants to join a thread\, she would declare this\, and *then* the behaviour you describe should make sense.

No. Given the current joinable by default state\, the current behaviour is perfectly sensible. It's the only way it can be done and still have eval work to catch thread errors.

Perl threads are conceptually async subs. You can eval a normal sub to catch errors so you should be able to eval an async one to catch its errors. The only way to reasonably do this\, since we can't un-throw an error\, is to hold the error a thread might have thrown and deliver it at a known time\, currently at join. (Which is the only reasonable place I can think of)

Yes\, this will confuse the naive or inexperienced perl developer. So will XS or funky symbol table tricks. All that means is They Shouldn't Do That\, and we should better document things. I've got perlthread.pod buried someplace on the laptop here--I'll have to finish it up and get it in.

Then you've got a mildly deficient threading library. Perl threads will probably never have priorities--they're a touch high-level for that to be really safe. Your platform's threading library should parcel out CPU time to the various threads in your program as it sees fit.

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

Ilya\, perl threads are too high a level construct to safely implement priorities. Plus we make no guarantees as to how perl threads map to OS threads. This isn't C\, after all\, and we're not writing device drivers. *Far* too much goes on under the hood for me to be comfortable with implementing priorities. (Which is also why we'll never get true async cancellation\, but not too many people'll argue for that one)

  Dan

----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From @samtregar

On Tue\, 19 Oct 1999\, Ilya Zakharevich wrote​:

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

What kind of priorities are you talking about? If you mean soft priorities\, where you're just making suggestions - I can't see that as an absolute necessity. After all\, by their very nature soft priorities aren't something you can count on! If you're talking about hard real-time priorities - what are the chances that we can implement that right without a hard real-time OS beneath us?

I'd love to see hard RT behavior in Perl on RT platforms\, but I think there's a lot of work to be done before that could even be a possibility!

-sam

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 06​:10​:58AM -0400\, Dan Sugalski wrote​:

Perl threads are conceptually async subs.

*This* is a bug. This is a shell programer's view of the threaded world.

There should be a way to create a "real" thread\, which never stops (until the process end\, when OS kills it).

Yes\, this will confuse the naive or inexperienced perl developer. So will XS or funky symbol table tricks. All that means is They Shouldn't Do That\, and we should better document things. I've got perlthread.pod buried someplace on the laptop here--I'll have to finish it up and get it in.

XS\, symbol table etc do not stop people who want to do real work. They are heavy tools\, but powerful. Imagine a symbol table through which you can get to $_ and only it!

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

Ilya\, perl threads are too high a level construct to safely implement priorities.

This I do not follow. What "highlevel" has to do with priorities? If the primitives Perl provides/uses-internally avoid priority inversion\, what is the problem?

Plus we make no guarantees as to how perl threads map to OS threads. This isn't C\, after all\, and we're not writing device drivers.

Threads are not device drivers. Threads are very simple building blocks\, everyday's idioms of today's programming. Perl threads should not be less.

*Far* too much goes on under the hood for me to be comfortable with implementing priorities. (Which is also why we'll never get true async cancellation\, but not too many people'll argue for that one)

If async cancellation would work in C\, I would see no reason why it cannot work in Perl (modulo the usual signallish mess). I see no relationship to priorities here.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 11​:30​:24AM -0400\, Sam Tregar wrote​:

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

What kind of priorities are you talking about? If you mean soft priorities\, where you're just making suggestions - I can't see that as an absolute necessity. After all\, by their very nature soft priorities aren't something you can count on! If you're talking about hard real-time priorities - what are the chances that we can implement that right without a hard real-time OS beneath us?

I mean priorities in between. Hard/soft priorities which "work". You need a "soft-RT" system for this\, but OS/2 is\, and I've heard that Solaris is at least close to too.

Ilya

[p5pRT]

From @samtregar

On Wed\, 20 Oct 1999\, Ilya Zakharevich wrote​:

I mean priorities in between. Hard/soft priorities which "work". You need a "soft-RT" system for this\, but OS/2 is\, and I've heard that Solaris is at least close to too.

Sorry to be a pain\, but could you define what a "soft-RT" system is exactly? As far as I know Solaris can be set into a hard RT mode\, but that in its default state it has no hard RT aspects. Defining "soft" RT can be very difficult\, and I've never heard of a definition for a "soft-RT" system.

-sam

[p5pRT]

From [Unknown Contact. See original ticket]

Sam Tregar wrote​:

On Wed\, 20 Oct 1999\, Ilya Zakharevich wrote​:

I mean priorities in between. Hard/soft priorities which "work". You need a "soft-RT" system for this\, but OS/2 is\, and I've heard that Solaris is at least close to too.

Sorry to be a pain\, but could you define what a "soft-RT" system is exactly? As far as I know Solaris can be set into a hard RT mode\, but that in its default state it has no hard RT aspects. Defining "soft" RT can be very difficult\, and I've never heard of a definition for a "soft-RT" system.

-sam

This link has (IMHO) has a "good enough" definition​:

  http​://www.realtime-os.com/rtmanifesto/rtmani_4.html -- Peter Wolfe Tel​: (604) 303-2300 Telos Engineering Limited\, http​://www.teloseng.com 120 - 13120 Vanier Place\, FAX​: (604) 276-0501 Richmond\, BC\, V6V 2J2. email​: wolfe@​teloseng.com

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 02​:32​:36PM -0400\, Sam Tregar wrote​:

On Wed\, 20 Oct 1999\, Ilya Zakharevich wrote​:

I mean priorities in between. Hard/soft priorities which "work". You need a "soft-RT" system for this\, but OS/2 is\, and I've heard that Solaris is at least close to too.

Sorry to be a pain\, but could you define what a "soft-RT" system is exactly? As far as I know Solaris can be set into a hard RT mode\, but that in its default state it has no hard RT aspects. Defining "soft" RT can be very difficult\, and I've never heard of a definition for a "soft-RT" system.

I'm a layman. You will not get a definition from me.

I know that OS/2 is not designed to be hard-RT system\, but if delays of order of 10ms are tolerable\, OS/2 *can* be used to serve such problems. This is "soft"-RT.

There is a guarantie that the OS is in non-interrable state for no more than 4ms at a time. There is a guarantie that in interrable state a thread in "time-critical" priority group will be started immediately if it is ready-to-run and there is no ready threads in the same or higher priority. It is guarantied that a thread of time-critical priority group will not run for longer than 8ms if another thread of the same priority is waiting.

[There are also 3 other priority groups with laxer scheduling guaranties. Basically\, if you do not serve time-critical hardware\, you do not go into time-critical priority group.]

This is whooping 50% of what I know. ;-)

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 01​:22 PM 10/20/99 -0400\, Ilya Zakharevich wrote​:

On Wed\, Oct 20\, 1999 at 06​:10​:58AM -0400\, Dan Sugalski wrote​:

Perl threads are conceptually async subs.

*This* is a bug. This is a shell programer's view of the threaded world.

Oh\, please Ilya. Just because the model that's implemented doesn't match what you want doesn't make it a bug.

There should be a way to create a "real" thread\, which never stops (until the process end\, when OS kills it).

Currently not possible. Exiting the main thread kicks off final GC\, which really screws up any currently running threads. And waiting for those threads isn't a particularly optimal solution--you're exiting\, so they should die. Waiting could hold you up forever.

You can always detach a thread\, but it still better exit before your program falls off the end of the world.

Yes\, this will confuse the naive or inexperienced perl developer. So will XS or funky symbol table tricks. All that means is They Shouldn't Do That\, and we should better document things. I've got perlthread.pod buried someplace on the laptop here--I'll have to finish it up and get it in.

XS\, symbol table etc do not stop people who want to do real work. They are heavy tools\, but powerful. Imagine a symbol table through which you can get to $_ and only it!

And your point is what\, exactly? Threads *are* a powerful tool\, and they're something that a vast majority of the folks writing perl code are pretty much completely unfamiliar with.

Threads without priorities are oximorons (sp?). There *are* some situations when you can live without priorities\, and there are platforms which cannot sanely work with prioritized threads\, but we should not cater to a lowest common denominator.

Ilya\, perl threads are too high a level construct to safely implement priorities.

This I do not follow. What "highlevel" has to do with priorities? If the primitives Perl provides/uses-internally avoid priority inversion\, what is the problem?

Past a certain point\, priorities are pretty meaningless. Perl does a *lot* for you--there just isn't the low-level control you can get with C or another 3GL. On the other hand\, it's only more rope. We're not forcing anyone to hang themselves. (It may make behind-the-scenes threadpooling and fake threads tougher\, though)

Plus we make no guarantees as to how perl threads map to OS threads. This isn't C\, after all\, and we're not writing device drivers.

Threads are not device drivers. Threads are very simple building blocks\, everyday's idioms of today's programming. Perl threads should not be less.

Of today's programming for *who*? Your average perl programmer? Doubt it. Your average programmer in general? Doubt it. Threads require an async mindset that most folks just aren't up for. (And while it sounds like I'm arguing against them\, I'm not\, but most folks just Won't Get It)

*Far* too much goes on under the hood for me to be comfortable with implementing priorities. (Which is also why we'll never get true async cancellation\, but not too many people'll argue for that one)

If async cancellation would work in C\, I would see no reason why it cannot work in Perl (modulo the usual signallish mess). I see no relationship to priorities here.

Async cancel doesn't work for C. Or anyplace else that I've seen. For perl to be async cancel safe we'd have to pepper the core with calls to turn it off and on. (It'd probably be off far more than it'd be on\, and off at those places it'd be most useful)

  Dan

----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 04​:12​:10PM -0400\, Dan Sugalski wrote​:

Perl threads are conceptually async subs.

*This* is a bug. This is a shell programer's view of the threaded world.

Oh\, please Ilya. Just because the model that's implemented doesn't match what you want doesn't make it a bug.

Why? It bugs me.

There should be a way to create a "real" thread\, which never stops (until the process end\, when OS kills it).

Currently not possible. Exiting the main thread kicks off final GC\, which really screws up any currently running threads. And waiting for those threads isn't a particularly optimal solution--you're exiting\, so they should die. Waiting could hold you up forever.

Absolutely. Threads marked as never-ending should be killed without mercy. This is what OS will do anyway. Currently you need to do it manually in an END block\, right?

And your point is what\, exactly? Threads *are* a powerful tool\, and they're something that a vast majority of the folks writing perl code are pretty much completely unfamiliar with.

My point is that this should not stop us from making it simpler/more-powerful.

This I do not follow. What "highlevel" has to do with priorities? If the primitives Perl provides/uses-internally avoid priority inversion\, what is the problem?

Past a certain point\, priorities are pretty meaningless. Perl does a *lot* for you--there just isn't the low-level control you can get with C or another 3GL.

Like what?

Ilya

[p5pRT]

From @samtregar

On Wed\, 20 Oct 1999\, Ilya Zakharevich wrote​:

I know that OS/2 is not designed to be hard-RT system\, but if delays of order of 10ms are tolerable\, OS/2 *can* be used to serve such problems. This is "soft"-RT.

That seems highly suspicious to me - doesn't OS/2 run on x86 hardware?
How do they deal with interrupt handlers potentially taking longer than 10ms (or 1000 of them taking longer than 1/100th in a given slice\, more realistically) and masking interupts?

There is a guarantie that the OS is in non-interrable state for no more than 4ms at a time.

But no possible garauntee that other processes aren't\, right?

It is guarantied that a thread of time-critical priority group will not run for longer than 8ms if another thread of the same priority is waiting.

Again\, on x86 hardware\, I don't see that this is possible unless you implement some painful restrictions.

This is whooping 50% of what I know. ;-)

But it should be enough to demonstrate that priorities exist at a MUCH lower-level than Perl. Can you imagine Perl providing an interface to this mess and still being even vaguely cross-platform. So far as I know there's nothing even *close* to a standard behavior here.

NOTE​: I'm not an expert on RT systems! If someone with greater knowledge sees flaws in my analysis I invite you to roast me.

-sam

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 05​:04​:39PM -0400\, Sam Tregar wrote​:

I know that OS/2 is not designed to be hard-RT system\, but if delays of order of 10ms are tolerable\, OS/2 *can* be used to serve such problems. This is "soft"-RT.

That seems highly suspicious to me - doesn't OS/2 run on x86 hardware?
How do they deal with interrupt handlers potentially taking longer than 10ms (or 1000 of them taking longer than 1/100th in a given slice\, more realistically) and masking interupts?

Am OS/2 device driver is free to do whatever it pleases. You are free to not install such drivers. ;-) AFAIK\, drivers which are shipped with OS should pass the test.

There is a guarantie that the OS is in non-interrable state for no more than 4ms at a time.

But no possible garauntee that other processes aren't\, right?

A process can be in non-interrable state only inside a system call.

It is guarantied that a thread of time-critical priority group will not run for longer than 8ms if another thread of the same priority is waiting.

Again\, on x86 hardware\, I don't see that this is possible unless you implement some painful restrictions.

Well\, the idea is that the pain goes to OS designers\, not to you. ;-)

This is whooping 50% of what I know. ;-)

But it should be enough to demonstrate that priorities exist at a MUCH lower-level than Perl.

???? What do you mean?

Can you imagine Perl providing an interface to this mess...

This is not a mess. It is a very clean and a very smoothly working system. And Perl already provides the interface​: setpriority(). Currently on OS/2 it is not defined how this interacts with threading\, but I think what it *does* with $$-argument is to set the *current* thread priority.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 04​:16 PM 10/20/99 -0400\, Ilya Zakharevich wrote​:

On Wed\, Oct 20\, 1999 at 04​:12​:10PM -0400\, Dan Sugalski wrote​:

Perl threads are conceptually async subs.

*This* is a bug. This is a shell programer's view of the threaded world.

Oh\, please Ilya. Just because the model that's implemented doesn't match what you want doesn't make it a bug.

Why? It bugs me.

Yeah\, but that doesn't make it a bug in perl. Merely a source of annoyance.

There should be a way to create a "real" thread\, which never stops (until the process end\, when OS kills it).

Currently not possible. Exiting the main thread kicks off final GC\, which really screws up any currently running threads. And waiting for those threads isn't a particularly optimal solution--you're exiting\, so they should die. Waiting could hold you up forever.

Absolutely. Threads marked as never-ending should be killed without mercy. This is what OS will do anyway. Currently you need to do it manually in an END block\, right?

Or something. If not in END\, then before exiting.

Unfortunately perl *can't* safely nuke threads in a number of cases (including when embedded) as it'll cause problems. I'm not entirely sure it's safe to nuke a thread at any time\, though the risk is low at program exit. The threads would have to be killed before final GC\, which makes things dicey\, 'cause who knows what state they'll be left in? Unpleasant all around.

And your point is what\, exactly? Threads *are* a powerful tool\, and they're something that a vast majority of the folks writing perl code are pretty much completely unfamiliar with.

My point is that this should not stop us from making it simpler/more-powerful.

Yeah\, but nothing you've said really does any of that. Starting detached is trivial. Changing priorities is essentially trivial.

This I do not follow. What "highlevel" has to do with priorities? If the primitives Perl provides/uses-internally avoid priority inversion\, what is the problem?

Past a certain point\, priorities are pretty meaningless. Perl does a *lot* for you--there just isn't the low-level control you can get with C or another 3GL.

Like what?

Like guaranteed timing. Like reasonable expectation of execution time. Like knowing what system calls will be made. Like knowing when memory will be allocated.

Using perl means the programmer abdicates a lot of control to the interpreter. That's fine\, but messing around with things likely to cause starvation and hangs\, like priorities\, is dangerous in those circumstances.

  Dan

----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Oct 20\, 1999 at 05​:22​:31PM -0400\, Dan Sugalski wrote​:

My point is that this should not stop us from making it simpler/more-powerful.

Yeah\, but nothing you've said really does any of that. Starting detached is trivial. Changing priorities is essentially trivial.

Then it should go into the API.

This I do not follow. What "highlevel" has to do with priorities? If the primitives Perl provides/uses-internally avoid priority inversion\, what is the problem?

Past a certain point\, priorities are pretty meaningless. Perl does a *lot* for you--there just isn't the low-level control you can get with C or another 3GL.

Like what?

Like guaranteed timing. Like reasonable expectation of execution time. Like knowing what system calls will be made. Like knowing when memory will be allocated.

All this is needed only in hard-RT time world\, which today is far away from Perl.

Using perl means the programmer abdicates a lot of control to the interpreter. That's fine\, but messing around with things likely to cause starvation and hangs\, like priorities\, is dangerous in those circumstances.

Hmm? Either it is Perl\, or it has training wheels. Choose one.

With a sane threading API you need a lot effort to cause (non-obvious) starvation and hangs by changing priority - unless it is what you want. ;-) If somebody starts a high-priority thread and starts a long-going "calculation" there\, then it is probably what they need.

Ilya