to dry
deserts and make them safe for camel caravans. :)
I'll be at yapc::eu
--
Alan Burlison
--
Dan Sugalski wrote:
The more I think about this the more I want to punt on the whole idea.
Cross-platform async IO is just one big swamp.
Agreed. Glug, glug, glug ;-)
--
Alan Burlison
--
r to re-modify
| them just corrupts them.
|
| Now, if there is a lock that is acquired *only* while in a signal
| handler, then it is sufficient to block all signals while in the signal
| handler (and this can be accomplished with no additional overhead by
| doing sigfillset(&action.sa_mask) before using 'action' to set up
| the signal handler).
Hope that helps,
--
Alan Burlison
--
nals during the queue operations, take out the
lock, do the work, drop the lock then reenable signals.
--
Alan Burlison
--
kes assumptions about execution order without using the necessary
mutexes/cvs to enforce these assumptions, it is very unlikely to work on
large SMP machines, for example.
--
Alan Burlison
--
ker, but that looks *very* suspect to me. Some compilers
may choose to reorder even without optimization turned on. I'd say that it
is a bug in Parrot if it requires optimization to be off for this code - how
many different compilers have you tried?
--
Alan Burlison
--
s...
Yes, all platforms that support LP64, i.e. virtually all 64-bit address
space platforms.
Sparc is just one example.
--
Alan Burlison
--
$ head -1 /dev/bollocks
refactor service-led meta-services, going forwards
ring :-)
Oops - so you were. Soz!
--
Alan Burlison
--
$ head -1 /dev/bollocks
visioneer 24/365 niches
ar\n");
prints out "FOO | BAR"
This is a really useful feature because it means that you don't need huge
lookup tables to convert from the numeric to the string version of a
constant - it is both at the same time.
--
Alan Burlison
--
$ head -1 /dev/bollocks
immutably engage omnipresent server-centric drivers
> autoconf automake libtool
Has anyone said 'Jam' on this thread yet? Jam is a platform-independent
make replacement, see http://www.perforce.com/jam/jam.html
--
Alan Burlison
--
$ head -1 /dev/bollocks
build high-visibility pervasive knowledge capital
tem has real registers, it's just at some
point they may end up in memory. That's not the same as indexing into
memory on every access.
Alan Burlison
ters.
Not a system call but a trap - they aren't the same thing (pedant mode off
;-). The register spill trap handler copies the relevant registers onto the
stack - each stack frame has space allocated for this.
Alan Burlison
straction is a
laudable aim, in the case of perl it has turned from abstraction into
obfustification.
Alan Burlison
Dave Mitchell wrote:
>
> All entities should be prefixed with the name of the subsystem they appear
> in, eg C, C. They should be further prefixed
> with the word 'perl' if they have external visibility or linkage,
>
Duh! Missed it. Thanks.
Alan Burlison
I see nothing about namespacing, e.g. Perl_
Alan Burlison
Uri Guttman wrote:
> malloc normally doesn't care about alignment.
I'll think you will find it does care.
Alan Burlison
only works with the Sun compilers.
However, there is an explanation of how it works that might be useful
when considering how to do this for perl6. I've attached the HTML -
sorry about the broken links, but I don't think this is on any
externally-visible webpage.
Alan Burlison
Alan Burlison wrote:
> I've attached the HTML
Well it was there when I sent it... does this list strip attachments or
something?
Here is is as badly-formatted text - sorry!
Alan Burlison
Appendix A: How Sun WorkShop Memory Monitor Works
Memory management in C/C++ is both time c
[EMAIL PROTECTED]
PIT - Perl Intergration Testers
Alan Burlison
Dan Sugalski wrote:
> Grab one via a utility function. getPMC() or something of the sort.
newPMC() ? ;-)
Alan Burlison
hink macro languages suck, whether they are the C macro preprocessor,
or some fancy dohickey that we knock together. I think that having to
have perl5 around to build perl6 also sucks. For example, in our case
we build perl5 every night with the rest of Solaris. It already takes
too long. Adding a build of perl5 just to build perl6 - well, forget
it.
Alan Burlison
't be freed and re-malloced much. If we're passing in a PMC
> pointer, we won't be reallocating the memory pointed to--rather we'll be
> reusing it.
So how do you get hold of a PMC from the arena in the first place?
Alan Burlison
scheme will
require the heay use of mutexes in a MT program.
Alan Burlison
slate
situation. We may well have to deliberately carry over questionable but
depended-upon behaviour into perl6.
my $fh = do { local *FH; *FH; }
for example, better continue to work.
Alan Burlison
t;bar\n";
}
At present "file" will contain "foo\nbar\n". Without DF it could just
as well be "bar\nfoo\n". Make no mistake, this is a major change to the
semantics of perl.
Alan Burlison
Branden wrote:
> Any suggestions?
Yes, but none of them polite.
You might do well to study the way perl5 handles these issues.
Alan Burlison
cted regime - even with
this restriction, and with the bugs I've already fixed the test suite
contains 141 memory errors.
The truth of the matter is that I suspect eval and die will always leak
until it is re-architected in perl6 - whenever that might be.
Alan Burlison
Branden wrote:
> Where can I find how Perl5's stack works (specially about parameter passing
> and returning from subs)?
Oh boy. What a masochist.
;-)
Alan Burlison
easier than faking threads. so we code all the internals to an
> event loop api and fake it underneath as needed on various
> platforms. much more on this soon.
As Jarkko would say:
Yes, yes yes.
:-)
Alan Burlison
-- thread# 3
ff35d6e4 _reap_wait (ff382a50, 20bf8, 0, ff37e000, 0, 0) + 38
ff35d43c _reaper (ff37ee80, ff3847b0, ff382a50, ff37ee58, 1, fe40)
+ 38
ff36b4a0 _thread_start (0, 0, 0, 0, 0, 0) + 40
Alan Burlison
is is the smallest safe set
> of things we can do, and I'm reasonably sure that everything else anyone
> might want can be layered on top, albeit slowly in some cases.
A very sound strategy IMHO.
Alan Burlison
> But the short answer (while it may suffice for perl6) is no use to me
> as a perl5 maintainer.
Well, we all have our particular crosses to bear ;-)
At the risk of being boring: Threads in perl5 are irredeemably broken
and should not be used.
Alan Burlison
n of apps are MT vs AIO, and which is
most likely to be available, well tested and well supported?
Alan Burlison
from being one character
shorter, that is.
However, having previously been told to shut up on this subject, I now
will.
Alan Burlison
y sense to tag the various
bits.
Alan Burlison
cursing/hacking/cursing
cycle on the existing POD tools. Do we really want to continue?
Personally I think POD sucks bigtime, although I'm sure hordes of people
will now spring up to defend it. I still think that with the correct
DTD writing the specs in XML would be doable.
Alan Burlison
Nathan Torkington wrote:
> Alan Burlison writes:
> > seem a very optimal way to go about it. How about a design document
> > (format to be decided) and a 'design + commentary' document which is the
> > design document with the condensed email discussion inserte
s generated by writing
a DTD for the spec and then transforming the document into the frameset
and html files. That would be the obvious way to do it. That way when
writing the document the commentary could be kept inline, which would
make it much easier for the author.
Alan Burlison
Simon, which I think is a really, really useful thing - you can use
it to get the essence of what went on and why, and then drill down to
the meat if you need to.
Alan Burlison
which they
appeared. I just hope the code is produced at the same prodigious rate
;-) As I said I was becoming increasingly dismayed by the continuing
stream of RFCs, and in the end felt I had to raise the issue. Having
done so I have been very happy to see the wide consensus that seems to
be appearing.
Alan Burlison
dea up, and if it gets shot at enough,
retire it - is a lead that hopefully others will follow. I kept looking
at the ever-increasing number of often conflicting RFCs (as you have
identified) with an increasing sense of foreboding, as none of them
seemed to be subject to the effects of natural selection and becoming
extinct.
Once again, Thanks!
Alan Burlison
knows in
>advance how it will work and nobody feels like it's an arbitrary
>"management" (ha!) decision.
Please make strenuous efforts to lay out the ground rules as soon as
possible.
> [this risk won't kill the project, though, merely hurt peoples' feelings]
It'll kill it if you hurt enough peoples feelings...
Alan Burlison
;re getting close, and I certainly
> agree that the human issues will indeed be a very big hurdle, probably the
> biggest hurdle facing the entire project.
Wrong, it should have been the first thing that was done. If it had,
the current mess wouldn't have happened.
--
Alan Burlison
"An optimist is a guy
that has never had
much experience."
-- Don Marquis --
d I hope I am. However, past bitter
experience tells me that I'm probably at least partly correct, so please
don't discard my comments out of hand.
I'm sorry but I really can't stomach watching this slow motion train
wreck any longer, so good luck and goodbye.
Alan Burlison
t unsubscribe.
It's doomed.
Alan Burlison
he change could not have taken
> place without an exclusive lock on the variable.)
>
> Then the execution stack and program counter would be reset to the
> checkpoint. And then restarted.
Sigh. Think about references. No, think harder. See?
--
Alan Burlison
ddressed the issue of what
constitutes and atomic operation.
> I think we all would agree that an op is atomic. +, op=, push, delete
> exists, etc. Yes?
Sorry - no I don't agree. As I said, what about map or grep, or sort?
I have an alternative proposal - anything that can be the target of a
tie is atomic, i.e. for scalars, STORE, FETCH, and DESTROY etc.
--
Alan Burlison
nd to allow this, how
will you know when to stop chasing references? What happens if there
are circular references? How much time do you think it will take to
scan a 4Gb array to find out which elements need to be checkpointed?
Please consider carefully the potential consequences of your proposal
controlled by the
> programmer.
Exactly. The intention behind the proposal to do auto-locking is
praiseworth - to make the programmers life easier. However, the
suggested solution is more akin to killing him with kindness.
--
Alan Burlison
please sumbit an RFC entitled "Why perl6 should
automatically fix all the broken programs out there and how I suggest it
should be done". Then you can sit back and wait for the phonecall from
Stockholm ;-)
--
Alan Burlison
non-trivial problem that may best be solved by keeping the entirety of
such modules private to a single thread. In that case the optree might
also have to be private, and with that and private work area it looks
very much like a full interpreter to me.
--
Alan Burlison
ue :shared;
> push(@queue, $b);
Again, all of these would have to be OK in an interpreter that ensured
internal consistency. The trouble is if you want to update both $a, %h
and @queue in an atomic fashion - then the application programmer MUST
state his intent to the interpreter by providing explicit locking around
the 3 updates.
--
Alan Burlison
erl5's death have been greatly exaggerated. I'm
sure you know that already, and I think you could have been more careful
with your choice of wording.
Alan Burlison
I found the following reference in the p5p archives to a paper
discussing open source development. I think this should be mandatory
reading for anyone contemplating a contribution to the RFC mountain.
http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
Alan Burlison
is a fools
errand. It is about as sensible as removing BLOCKS and getting perl to
guess where they should go.
--
Alan Burlison
ild a seperate optree for each module as
it is loaded, and for each thread/interpreter to hold a reference to the
ones that it uses. This way the optrees could remain readonly, but
still be shared if required and safe to do so. If no extant threads
refer to the optree, it could perhaps be freed - sort of
reference-counted optrees. I'm winging it a bit here becasue I don't
know if this is a good idea/vaguely possible/barking mad (choose one).
--
Alan Burlison
This will however require that different threads
are allowed to have different optrees - perhaps some sort of 'copy on
write' semantic should be used so that optrees can be shared cheaply for
the cases where no changes are made to it.
Alan Burlison
be utterly useless. And, how on earth will you
identify sections that "only operate on internal data"?
--
Alan Burlison
of joint, but
it is true. Doesn't it occur to people that if it was easy to add
automatic locking to a threaded language it would have been done long
ago? Although I've seen some pretty whacky Perl6 RFCs, I've yet to see
one that says 'Perl6 should be a major Computer Science research
project'.
--
Alan Burlison
ow some bits
of a .so may not be shared, but most of it is). Paging involves disks,
and they are orders of magnitude slower than the dynamic linking
overhead. Repeat the excercise with a couple of hundred concurrent
copies of your test. Drawing conclusions based on a single test can be
misleading.
--
Alan Burlison
piped in on stdin, it might mean a few milliseconds shaved off
> startup.
You already have this win:
# Force symbol resolution on startup
$ LD_BIND_NOW=1 ptime perl -e 'exit(0)'
real0.029
user0.021
sys 0.007
# Default lazy linking
$ ptime perl -e 'exit(0)'
real0.019
user0.010
sys 0.007
Alan Burlison
ome bits of the core so that they don't
depend on anything else, but I'm far from persuaded the overall benefit
will be worth the extra complications.
Alan Burlison
= 'Longs and Pointers are 64 bit'. There are several
other alternatives too, although most everyone seems to have settled on
LP64. See the paper at
http://www.unix-systems.org/version2/whatsnew/lp64_wp.html
--
Alan Burlison
Solaris Kernel Development, Sun Microsystems
tform dependent implementation mechanisms invisible to
applications.
--
Alan Burlison
Mark-Jason Dominus wrote:
> If we're going to standardize on a single time format for all
> platforms, I wish we could choose a good format. Unix time runs out
> in 2038.
Not true. On 64 bit Unix platforms time_t is 64 bit.
Alan Burlison
ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
$ ./t
time_t is 32 bits
$ cc -o t t.c -xarch=v9
$ file t
t: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
$ ./t
time_t is 64 bits
--
Alan Burlison
messages as read when it is run.
PERL_LIST='(perl|bootstrap|scripts)[^@,;= ]*'
:0 Wh: .perl-lists.lock
* $ ^TO_\/${PERL_LIST}@perl\.org
* MATCH ?? ^^\/[^@]+
| formail -D 8192 .perl.msgid
:0 e:
perl-lists/$MATCH
Alan Burlison
67 matches
Mail list logo
