nd expensive way of doing something 'simple'.
And I can't imagine how this would work. Any statement could be interupted
with an exception, but there is no mechanism to restart.
This is just plain wrong.
--
Chaim Frenkel
ne CWD, which is shared by all threads. This means
PRL> that the C interface is intrinsically broken under
PRL> threads.
Not really, what if two threads need different current directories?
Same problem, you are just pointing the finger.
The others are 'broken' even without threads.
o == 3.
push( &fn(), 35)
could be made to work. No longer would a list be returned but an
unnamed array. Hmm, might work together with lvalued subs.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
need two or more variables kept in
sync. The user has to mediate. Perl can't determine this.
Perhaps, I'm archaic, but I really wouldn't mind if the thread model
basically copied the fork() model and required those variable that have
to live across threads to be marked as :shared.
ases here. I've been doing perl since
sometime in the mid perl4's and clearly I haven't run into something
that depended upon this.
I wonder how much it would hurt the -internals work.
I think I'm not alone in wanting to make the list/array dichotomy go away.
--
Chaim Fr
alar context . But with $x=(, (), ...), why shouldn't the
nested set of parenthesis make its insides into a list.
Perhaps that's my block. For me the return takes away the thrust of the
outside scalar context.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
st, it should not have its comma
changed?
Will my proposal bleed into anything else in the language?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
he user?
Perhaps a warning if the contents of a :shared variable moves into a
non-shared variable.
Alternatively, the thread doing the moving, somehow takes ownership
of the contents, and makes the contents unavailable to any other thread?
Thoughts?
>>>>> "CF"
list context, but the $x imposes a scalar
context on the 'list' at the end. (To keep something of backward
compatablity, it probably would need to act differently if the @
is not in the final position.)
Now here is where it would probably break, and give you a fit trying to
explain it.
uire a :shared on variable anything and everything
has to have protection. If you want the variable to be shared
declare it.
SWM> Example 3: Closures (Ken's example)
Aha, I get it. -internals has been assuming that one _must_ specify
the sharing. You want it to be infered.
I
t a listish thing. One should learn.
I don't want that to change. I simply want that return (I'm not sure
how to phrase this) be able to return only a scalar or an aggregate.
It should be immune from having a scalar context pushed through from
the caller and change the com
r perhaps
something else entriely.
Would making closures only under direct instructions be something useful?
It would add some typing, but would be a guide to both the reader and
perl (and perhaps, prevent some unanticipated closures from being created.)
--
Chaim Frenkel
er me. It might be worthwhile enough
to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
ed this. I'm not wild about the syntax,
JSD> but I like the idea. If everything become objects under-the-hood,
JSD> then we could have:
JSD>for $a (@array) { print "$a is at $a->index\n"; }
JSD> No, I'm not wild about that either, but it's an idea.
easily be done by the user
and probably a lot more efficiently then the pessimistic locking perl
would need to perform.
>>>>> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Chaim Frenkel wrote:
>>
>> >>>>> "DLN&qu
e subroutines _it_ will call? And if you solve
that one, I'll throw in tied variables, and evaled statements, and ...
That way lies madness. Let us simply give the user the tools needed
to manage their locking.
--
Chaim Frenkel
threads per *second*. I cannot possibly get the performance
SWM> I need if every thread has to recompile all its own modules.
SWM> We could either discuss alternate approaches for RFC1, or I could
SWM> submit a new RFC for a thread architecture that gives me the
SWM> performance I wan
tatement boundaries.
Here's another one.
$x = 3 + &foo() - &bar();
Where does the yield happen? What happens to the yields that are already
in the 'optree' for foo and bar?
Cooperative only helps _perhaps_ with perl not needing to protrect its
own structures.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
inc_a);
SWM> my $t2 = Thread->new(\&inc_a);
SWM> $t1->join;
SWM> $t2->join;
SWM> print "$a";
SWM> sub inc_a
SWM> {
SWM> $a++;
SWM> }
SWM> What should the output be? 0? 1? 2?
SWM> - SWM
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
. It won't crash.
SWM> 2. After both threads run, $a and $b are both either "abcd" or "wxyz",
SWM>(and not, for example, "abyz").
SWM> If the user cares whether the final values of $a and $b are "abcd" or
SWM> &
layer (yeah, I know another speed loss) that
would be able to directly target the native threads library/api.
The POSIX threads API would be the initial port but then we might be
able to get some speed ups by going for the native implementation?
--
Chaim Frenkel
s building an optree and storing a pointer in the global
namespace (or package perhaps.)
BCW> (Assuming all program globals, of course.)
BCW> Thread 1: $a = $b + $c;
BCW> Thread 2: $d = $c / $a;
BCW> Thread 1, doing statement locking, could lock these $a, $
all <[EMAIL PROTECTED]> writes:
SWM> Does Perl6 support Symmetric MultiProcessing (SMP)?
SWM> This is a *huge* issue. It affects everything else that we do with
SWM> threads.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]
}" at the
PS> beginning of its block, does that not handle the problem without getting
PS> rid of the thing?
If you are doing a try, why are you bothering with $SIG{DIE}.
Any global should only be manipulated by one and only one level. The
main routine. (Even if it
. Otherwise you are just falling out of the BLOCK.
Why all the extra syntax? I see no gain to the programmer or to the
perl internals.
>>>>> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Chaim Frenkel wrote:
>>
>> Tony Olekshy wrote:
>>
every other decent exception handling mechanism. Perhaps it should be axed
PRL> altogether. Please.
$SIG{DIE} should die. Action at a distance. Global. Can't know what
other threads or modules want done here.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
eptare, from exceptus, past participle of excipere to
take out, except, from ex- + capere to take
-- more at HEAVE
Date: 14th century
transitive senses : to take or leave out from a number or a
whole : EXCLUDE
intransitive senses
es it to start going through catch
PS> blocks again }
PS> then I'm afraid I'm going to have to turn to drink.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
ught_handler => sub { ...
PS> }, ... );
PS> And the dispatcher would look first in the object, then in the class for
PS> uncaught_handler.
PS> I think it's cool how this process is converging :-)
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
>>>>> "JM" == James Mastros <[EMAIL PROTECTED]> writes:
JM> On Mon, Aug 14, 2000 at 06:17:02PM -0400, Chaim Frenkel wrote:
>> Let us get away from the globals as much as we can. This can easily
>> (I think) be taken care of by having the _
eword), and sub
JM> {warn shift;}, print out a warning message (default warnings, like... I
JM> can't think of any).
JM> The value of onuncaught should follow isa if it doesn't exist.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
k, block, retrieve, unlock. we
UG> don't have that for filehandles. you could use a new method on that
UG> special handle (i like 'get') which has the desired semantics.
UG> i think making mailboxes in some form is a good idea. but they should be
UG> special objects (eve
rward
loop easier[1]. And if necessary, an external module can implement the
callback style[2].
Having both just adds complexity.
[1] I've done both styles and written both style dispatchers also.
[2] I think the loop can emulate the callback style
ttle extra overhead.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
; Timers can be used to break out of any AIO operation and even out of
PRL> eval blocks by having the callback execute die (or quit or whatever). So
PRL> you can nest eval blocks and have control over how long each level takes
PRL> to run. Also this means no more collisions with sharing alar
ate without the mess of directly dealing with
PRL> semaphores/mutexes/queues.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
ch
io event
calls to the yield operator
There are even more possiblities. None of which requires any mention
of how the internals are implemented.
As far as I can see there is nothing in the %SIG semantics that makes
it inherently unsafe. If there is please tell me why this isn't a
>>>>> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
CF> Please explain how any of this will make signals safer? Safer
CF> signals is a core issue. Not a language iss
PROTECTED]>
UG> Date: 07 Aug 2000
UG> Version: 1
UG> Mailing List: perl6-language-flow
UG> Number: TBD
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
39 matches
Mail list logo
