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