Just thought I'd share some more thoughts on threading. I don't think
the threading proposal is baked, yet, unfortunately.
I've come to agree with Dan: As the threading requirements and the
architecture stand, parrot requires frequent and automatic locking to
prevent crashes. This is completely
On Friday, January 23, 2004, at 11:09 , Dan Sugalski wrote:
Ah, OK, I see. The problem comes in where we've got an object in the
transient root set (basically the processor stack and registers) that
gets anchored into the base root set (stash, pads, or whatever) after
the DOD has traced where i
On Friday, January 23, 2004, at 09:39 , Dan Sugalski wrote:
At 12:05 PM +0100 1/23/04, Leopold Toetsch wrote:
So my local src/events.c does:
1) block all signals before any thread creation
2) install an event handler for SIGINT
3) start the event handler thread
4) start an IO handler thread, whi
On Fri, Jan 23, 2004 at 07:53:49PM -0800, Jonathan Lang wrote:
: Dave Whipp wrote:
: > But, presumably, you could write a macro that has a whitespace-eater
: > encoded
: > somehow. That is,
: >
: > macro leach() { chomp_trailing_whitespace; return "?" }
: > macro reach () { chomp_leading_whitespac
On Fri, Jan 23, 2004 at 06:43:04PM -0800, Dave Whipp wrote:
: "Larry Wall" <[EMAIL PROTECTED]> wrote in message
: news:[EMAIL PROTECTED]
: > That is, suppose you have:
: >
: > macro leach () { return "ï" }
: > macro reach () { return "ï" }
: >
: > You could unambiguosly write
: >
: > le
Dave Whipp wrote:
> But, presumably, you could write a macro that has a whitespace-eater
> encoded
> somehow. That is,
>
> macro leach() { chomp_trailing_whitespace; return "»" }
> macro reach () { chomp_leading_whitespace; return "«" }
>
> then the macro magic would expand "leach eq reach" as "»
On Fri, 2004-01-23 at 06:16, Dan Sugalski wrote:
> Hang it off the cache slot, and mark the cache as a buffer with the
> data you need in it. (That's how I'd do it, at least)
Something like this?
I'm having odd troubles with "Key not an integer!", which indicates I'm
doing something wrong. Sti
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> That is, suppose you have:
>
> macro leach () { return "»" }
> macro reach () { return "«" }
>
> You could unambiguosly write
>
> leach+reach
>
> but (assuming spaces not allowed within distributed operators) you
On Fri, Jan 23, 2004 at 05:20:41PM -0700, Doug McNutt wrote:
: I have been a lurker since early November. Dan S. suggested I get over
: here when I wrote a piece on the summary list describing my feelings
: about vector operations in perl 6. My information was based on the
: recent O'Reilly book an
On Fri, Jan 23, 2004 at 01:54:21PM -0800, Dave Whipp wrote:
: When I see these long squiggles of line noise, I can't help thinking that
: English might be a better alternative. Using Larry's terminology from a few
: posts ago, we might think of:
:
: @a \C[leach] + \C[reach] @b
:
: Not mnemonic
What the...
I had a parrot that was less than a week old, I thought... but the copy
I grabbed this morning now works fine.
Thanks, Leopold.
On Friday, January 23, 2004, at 04:08 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
... I found that the samples listed below both fa
I have been a lurker since early November. Dan S. suggested I get over here when I
wrote a piece on the summary list describing my feelings about vector operations in
perl 6. My information was based on the recent O'Reilly book and I had to confess that
I have never in my life opened a CVS file.
While we're about it, there's a need for platform specific .s files as well, since
some compilers like xlc don't support inlined asm. There's a ia64.s already in cvs,
but I don't see by what magic it actually gets built (if it even is). Configure
should likely have a --as option as well to sup
Deven T. Corzine wrote:
> The most novel approach I've seen is the one taken by Project UDI
> (Uniform Driver Interface).
This is very much the "ithreads" model which has been discussed. The
problem is that, from a functional perspective, it's not so much
threading as it is forking.
--
Gordon
On Fri, 23 Jan 2004 10:24:30 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
> If you're accessing shared data, it has
> to be locked. There's no getting around that. The only way to reduce
> locking overhead is to reduce the amount of data that needs locking.
>
One slight modification I would m
On Fri, Jan 23, 2004 at 10:07:25AM -0500, Dan Sugalski wrote:
> A single global lock, like python and ruby use, kill any hope of
> SMP-ability.
Assume, for the sake of argument, that locking almost every PMC
every time a thread touches it causes Parrot to run four times
slower. Assume also that
When I see these long squiggles of line noise, I can't help thinking that
English might be a better alternative. Using Larry's terminology from a few
posts ago, we might think of:
@a \C[leach] + \C[reach] @b
Not mnemonic in a visual sense, but extendable to all sorts of trigraph
contexts. Indee
Larry Wall writes:
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
> : Larry Wall writes:
> : > On the other hand, we've renamed all the
> : > other bitwise operators, so maybe we should rename these too:
> : >
> : > + : > +>bitwi
Dan Sugalski wrote:
At 5:24 PM -0500 1/22/04, Deven T. Corzine wrote:
Damian's issues were addressed before he brought them up, though not
in one spot.
A single global lock, like python and ruby use, kill any hope of
SMP-ability.
Hand-rolled threading has unpleasant complexity issues, is a bi
On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > On the other hand, we've renamed all the
: > other bitwise operators, so maybe we should rename these too:
: >
: > +< bitwise left shift
: > +> bitwise right shift
:
: I could h
At 10:54 AM -0500 1/23/04, Benjamin Kojm Stuhl wrote:
Well, that was why I had my suggested sample pseudocode restore the
previous vtable pointer before calling down to the next function
(and put itself back when that's done).
That has reentrancy issues, unfortunately. Potentially threading and
At 5:56 PM +0100 1/23/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
C was not marked reachable (although it was) and was thus
erroneously collected, leaving a dangling pointer. This problem
applies equally to copying and mark-
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
>>C was not marked reachable (although it was) and was thus
>>erroneously collected, leaving a dangling pointer. This problem
>>applies equally to copying and mark-sweep collectors.
> Ah, OK, I see.
That
At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
On Monday, January 19, 2004, at 06:37 , Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all readers should be blocked as well.
True of non-moving collectors, too. [...]
On Fri, Jan 23, 2004 at 02:19:37PM +0100, Michael Scott wrote:
> Is there a reason why the names have to be so terse?
>
> Mutable is not a bad word for able-to-change. (Cribbed from Cocoa,
> though there the immutability is absolute).
>
> *) Array - fixed-size, mixed-type array
> *) MutablePArra
-Original Message-
> Date: Fri Jan 23 09:27:12 EST 2004
> From: "Dan Sugalski" <[EMAIL PROTECTED]>
> At 10:37 PM -0500 1/22/04, Benjamin K. Stuhl wrote:
> >Dan Sugalski wrote:
> >>In addition to the thread autolocking front end and debugging front
> >>end vtable functions, both of which ca
At 5:58 PM -0500 1/22/04, Josh Wilmes wrote:
I'm also concerned by those timings that leo posted.
0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead
seems pretty crazy to me.
It looks about right. Don't forget, part of what you're seeing isn't
that locking mutexes is slow, it's that
At 6:38 AM -0800 1/23/04, Robert Spier wrote:
> Right, good point. In that case, if we could give our intrepid and
possibly slightly mad volunteers Dave Pippenger (dpippen) and
Stephane Peiry (stephane) privs on the bug and todo queue for parrot,
that'd be great -- we can start handing out todo
At 5:24 PM -0500 1/22/04, Deven T. Corzine wrote:
Dan Sugalski wrote:
Last chance to get in comments on the first half of the proposal.
If it looks adequate, I'll put together the technical details
(functions, protocols, structures, and whatnot) and send that off
for abuse^Wdiscussion. After th
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> All this stuff needs to get out of events.c at some point, and we
> probably better do it now rather than later.
Yeah. Thought about that too. I'm a bit unhappy with the current
config/gen/platform/* files.
Me thinks that we should do:
- s/generic/posix/
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ and another f'up myself ]
> The IO thread can then generate a SIGINT_EVENT and pthread_signal the
> event thread. And it could wait on various file-handles and on an
> internal pipe, which can be used to communicate file-handles to be
> waited on to th
At 2:19 PM +0100 1/23/04, Michael Scott wrote:
Is there a reason why the names have to be so terse?
No, I suppose not. Chalk it up to typing laziness, so the longer
names are certainly a viable option.
--
Dan
--"it's like
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #25239]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25239 >
We've got per-platform .c and .h files that get loaded in by
configure.pl, which is goo
At 12:05 PM +0100 1/23/04, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
The event handler thread is waiting on a condition, so the only
possibility seems to be the latter option, that is run another thread
that does nothing but sigwait(3).
While pressing $send_button I real
> Right, good point. In that case, if we could give our intrepid and
> possibly slightly mad volunteers Dave Pippenger (dpippen) and
> Stephane Peiry (stephane) privs on the bug and todo queue for parrot,
> that'd be great -- we can start handing out todo tickets to folks for
> doing.
done-o.
At 6:59 PM -0500 1/22/04, Will Coleda wrote:
Which kind of stops me dead in my tracks, as I'm loathe to put
things back to the old, bulky calling conventions.
Try throwing a prototyped on all the sub declarations (though that
ought not be necessary in the long run) and see if that helps.
Default
At 10:32 PM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I'm finding parrot's killing its memory pools somewhere and dying
when it goes to compact memory during a GC sweep.
Yep. See also "Memory corruption" by Steve Fink and my f'ups.
That's what I thought, but I
At 10:37 PM -0500 1/22/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
In addition to the thread autolocking front end and debugging front
end vtable functions, both of which can be generic, there's the
potential for tracing and auditing front end functions, input data
massaging wrappers, and a
At 10:33 PM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:28 AM +0100 1/22/04, Leopold Toetsch wrote:
And mainly the return convention are still broken.
I thought those were fixed.
Not yet.
I looked--PDD 03 is fixed, and has been for quite a while.
> ...
At 12:47 PM -0800 1/22/04, chromatic wrote:
On Thu, 2004-01-15 at 09:16, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If that's living in an managedstruct, then accessing the struct
> elements should be as simple as:
> set I0, P20['bar']
> set S1, P20['plugh']
>
At 2:05 AM + 1/23/04, [EMAIL PROTECTED] wrote:
The subject says it all.
As Leo's pointed out, that's what the compile op is for. It takes
both a string with the source to compile as well as the name of the
compilation module to pass it to. This currently works with the
modules "PIR" and "PAS
At 2:39 AM -0500 1/23/04, Joseph Ryan wrote:
As far as Perl6 (which will be written in Perl6)
That, as they say, turns out not to be the case. Most of perl 6 will
probably be written in C...
--
Dan
--"it's like this"-
At 10:40 PM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The only tricky bit comes in with the examination of the root set of
other threads--accessing the hardware register contents of another
running thread may be... interesting. (Which, I suppose, argues for
At 12:56 PM -0800 1/22/04, Robert Spier wrote:
> Is there any way to get RT to close tickets (or change their status)
entirely via e-mail? That'd make this a lot easier if we could throw
a:
RT-Status: Closed
or something like it in the reply to a bug report that notes the bug
has been fixed.
Is there a reason why the names have to be so terse?
Mutable is not a bad word for able-to-change. (Cribbed from Cocoa,
though there the immutability is absolute).
*) Array - fixed-size, mixed-type array
*) MutablePArray - variable-sized PMC array
*) PArray - Fixed-size PMC array
*) MutableSArra
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> The event handler thread is waiting on a condition, so the only
> possibility seems to be the latter option, that is run another thread
> that does nothing but sigwait(3).
While pressing $send_button I realized, that there is another option and
- of co
Will Coleda <[EMAIL PROTECTED]> wrote:
> ... I found that the samples listed below both fail with:
Both samples run fine here. Do you have the latest parrot?
leo
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The subject says it all.
> As parrot is designed to be targetted by many langauges,
> how will it handle 'eval' opcodes for those different languages?
It'll be a sequence like this
loadlib Phandle, "your shared lib"
dlfunc Pcompiler, Phandle, "
The Plan(tm) AFAIK is to convert signals to events[1]. Pressing ^C on the
console or such should be available to user defined exception or signal
handlers.
So the flow of information would be:
1) signal async per definition - in some thread
2) event-handler thread co
[EMAIL PROTECTED] wrote:
The subject says it all.
As parrot is designed to be targetted by many langauges,
how will it handle 'eval' opcodes for those different languages?
Shell out to a seperate process?
As far as Perl6 (which will be written in Perl6) goes, an easy
solution is to design the
50 matches
Mail list logo
