This week's summary

[Piers Cawley]

The Perl 6 Summary for the week ending 20030629
Welcome to the third of my US tour Perl 6 summaries. Once again I'm
pleased to report that the denizens of the Perl 6 mailing lists continue
to make the life of a touring summarizer an easy one by not posting all
that much to the lists. So, I can sit here in my room at the Shaker Inn
in Enfield and marvel at the traffic noise outside, wonder about the car
next door with the New Hampshire plates reading PERLFAN, and just
generally appreciate the loveliness of the room.

But, while I'm doing that, I should start with perl6-internals

Exceptions
At the end of last week, Dan outlined his thoughts on how exception
handling will work in Parrot. This week, people talked about it.
Discussion revolved around how much information should be attached to an
exception and how/whether we should support resumable exceptions.

http://xrl.us/j73

More on Continuation Passing
Last week I said that "I get the strong feeling that Leo Tötsch isn't
entirely happy with the new Continuation Passing Style". This week Leo
corrected me; I hadn't noticed that the speed issues had been addressed
by the latest changes to parrot (in fact the current CPS implementation
is faster than the old "invoke/ret" scheme.

Sean O'Rourke addressed Leo's problem with the Perl 6 Compiler tests
failing by saying that the compiler should really be ported to use CPS
rather than implementing a new variant of the Sub PMC that uses the old
scheme. Leo reckoned that such a port wasn't currently doable because
IMCC needed to be modified to use the CPS scheme, which would also
involve reworking the register allocator. Given Leo's prodigious rate of
implementation, this may have already happened.

http://xrl.us/ktb

IMCC/Parrot leak
Clinton A. Pierce had reported a memory leak in Parrot, but tracked it
down to a situation where he was doing:

.arg 0
call _foo

And forgetting to take the 0 off the stack. However, even after he'd
fixed that, he had segfault issues, and posted a (largish) code fragment
that tweaked the bug.

It appears that Parrot wasn't throwing warnings when stacks get to big,
just failing silently. Leo added a check for too deeply nested stacks,
which at least avoids segfaulting on logic bugs.

Leo and Dan discussed other places where such limit checking should be
put in place. Dan also muttered something about turning stack chunks
into PMCs, allowing for the garbage collection of stack frames. Leo also
muttered about the proliferation of stack implementations in Parrot
(there are five) and thinks it should be possible to have one general
stack engine.

http://xrl.us/ktc

Making "+" a unary operator
Bernhard Schmalhofer found a problem with the Perl 6 implementation.

print +42, "\n";

printed '42', but omitted the carriage return. He fixed this by making
"+" into a unary operator as well as a binary operator and sent the
patch to the list, where it was applied. Good catch Bernhard.

http://xrl.us/ktd

ParrotIO File-Descriptors
Jürgen Bömmels is in the process of porting the IO subsystem from its
current "mem_sys_alloc/free" based implementation to the sunny, garbage
collected, uplands of a PMC based implementation. However, he's run into
a problem; some of the operations in op.ops use integer File
Descriptors, grabbing information from a table in the interpreter
structure. This gets in the way of garbage collection, since any integer
could be a file descriptor.

Jürgen proposed removing the integer file descriptors and mandating that
ParrotIO PMCs be the only way to access IO (including the standard
STDIN, STDOUT and STDERR). He proposed adding "get_std[in|out|err]" ops
to get at the standard streams.

Dan suggested that Jürgen Just Do It; the current IO system being more
than slightly hackish, it was essentially put in place until something
better came along.

http://xrl.us/kte

Small Perl task for the interested
Want to get involved in the Parrot development process? Don't know much
about Virtual Machine design and implementation? Do know Perl? Dan has a
small but interesting task for you.

At present, Parrot gets built without any compiler level optimizations
turned on because files like tsq.c can't have any optimizations turned
on (tsq.c is the thread safe queue module, which is "annoyingly
execution-order-dependent because it has to operate safely as interrupt
code potentially interrupting itself").

Dan would like a version of Configure.pl which can build a makefile (or
whatever build tool we end up using) with per-C-file compiler flags, and
it needs to be possible to override those flags, per file, by the
platform configuration module.

Interested? David Robins seems to be, and he asked whether the build
system had to be makefile based. Dan says not, but the really important
thing is that the resulting build script, or the config system that
generates the script be adequately understandable/maintainable.

http://xrl.us/ktf

Scoping, ".local" and IMCC
Bugfinder General, Clinton A Pierce is getting a headache trying to
understand ".local". When he executes the following code

.local int f
.sub _main
.local int x
.sub _foo1
f=1
x=2
call _foo2
end
.end
.sub _foo2
print "f is 1: "
print f
print "\n"
ret
.end
.end

the output looks like:

f is 1: 2

Which isn't quite what one would expect.

Leo explained what's going on; essentially it boils down to issues with
register allocation not being aware of ".local" scopes. He recommended
that Clint use either true globals or lexicals instead of ".local".
Clint isn't so sure that this is a good idea, pointing out that there
are occasions when having lexically scoped names at the IMCC level as
well as at the level of lexical pads would be very useful.

"In my mind, when I saw: 1. ".local", 2. automagical register spillage
in IMCC, and 3. nested compilation units I thought I'd found Assembler
Manna." -- Clint Pierce

http://xrl.us/ktg -- Clint is puzzled

http://xrl.us/kth -- Leo explains it all

Tentative valclone patch
Luke Palmer has been thinking about value and reference objects. He
wondered if there was any value in a "valclone" operator alongside "set"
and "clone" which would allow the target PMC to decide whether to use
"set" or "clone" semantics. He also offered a patch implementing the
operator if people thought it would be useful. Leo Tötsch wasn't sure
the new operator was necessary.

Klaas-jan Stol noted that he'd encountered problems with reference/value
confusion when he'd been working on his Lua compiler, but he wondered if
the problem couldn't be solved by having a general, language independent
"argument" PMC class. (I'm not sure I understood what he meant by this
so I'm hoping for an explanation with code fragments).

http://xrl.us/kti

Events, exceptions and threads. Oh my!
There is a story that UK prime minister Harold MacMillan was asked by a
student what it was that concerned him most as Prime Minister. Mac
replied "Events dear boy, events."

Leo Tötsch laid out his thoughts and ensuing questions about Exceptions,
events and threads, and how they played together. There has been a small
amount of discussion in response to this, but I think everyone's
currently thinking hard about the issue...

http://xrl.us/ktj

CPS and the call stack
Luke Palmer wondered if there would be a standard way of inspecting the
call stack (for debugging/"caller"/etc). (I think I'm going to switch to
using the phrase 'call chain' rather than call stack, as the presence of
continuations makes the call 'stack' look pretty unstacklike...).

Leo and Dan both thought that this would be a high level language issue
rather than a Parrot issue, though Dan did note that there might be
useful things that Parrot could do to make such introspection
easier/possible.

http://xrl.us/ktk

Continuation manipulation
Leo Tötsch has been thinking about occasions when one might need to
monkey with the internals of an existing continuation (he was thinking
about the 'warnings' state...) and proposed several solutions. Dan
favoured his new opcode, "updatecc" and thought it would be good to be
able to broaden the scope of what one could update in a
continuation/context. This scared Leo somewhat, but Dan came up with
some examples of where it might prove to be useful.

http://xrl.us/ktl

Meanwhile in perl6-language
Almost nothing happened, there were all of 15 messages.

Perl 6 Daydreams
Miko O'Sullivan engaged in some summer daydreaming by asking what
everyone was looking forward to most from Perl 6. Miko himself is
looking forward to more Pure Perl modules; if Perl 6 delivers on its
performance promises then there are going to be more and more things
where implementing directly in Perl will be fast enough, and Perl is so
much easier to implement in than C...

Jonathan Scott Duff incurred Cozeny when he said that he's hoping that
by this time next year we'll have an 85% complete Perl 6 that will be
usable in production (by brave people). Simon Cozens noted that we
already have such a beast and it's called Perl 5. For some reason this
led to a new marketing slogan being proposed: Perl 6, the reconstituted
cheeseburger of programming languages. Somehow I don't think that one's
going to fly. (I just read this bit out to my wife and she says that she
really doesn't like the thought of a flying reconstituted cheeseburger,
so I think we'd best leave it at that.)

http://xrl.us/ktm

Acknowledgements, Announcements and Apologies
Tcha! I announce the retirement of Leon Brocard from his post as Perl 6
Summary Running Joke and put the right to choose the next joke up for
auction at YAPC. And what do you know, the winner of the auction
nominates Leon Brocard as the new running joke. So, settle in for
another year of desperate rationalizations for mentioning Leon in these
summaries. Who knows, maybe Leon's Parrot related workrate will go up to
such an extent that it'll be easy, but somehow I doubt it.

Thanks to, in chronological order, Adam Turoff and Lisa Wolfisch; Walt
Mankowski, Mark Jason and Laurie Dominus; Dave Adler; Dan and Karen
Sugalski; and Uri and Linda Guttman for being such fine hosts in
Washington, Philadelphia, New York, Hartford and Boston respectively.
Next time we do this, we will not be attempting to visit quite so many
cities on the Eastern Seaboard in such a short time. At one point all we
were seeing was Perl nerds and freeways in rapid succession.

As ever, if you've appreciated this summary, please consider one or more
of the following options:

* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl.

* Get involved in the Perl 6 process. The mailing lists are open to
all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/
are good starting points with links to the appropriate mailing
lists.

* Send feedback, flames, money, photographic and writing commissions,
or a cute little iPod with a huge capacity to satisfy my technolust
p6summ...@bofh.org.uk.

--
Piers

[Alan Burlison]

Piers Cawley wrote:

> Small Perl task for the interested
> Want to get involved in the Parrot development process? Don't know much
> about Virtual Machine design and implementation? Do know Perl? Dan has a
> small but interesting task for you.
>
> At present, Parrot gets built without any compiler level optimizations
> turned on because files like tsq.c can't have any optimizations turned
> on (tsq.c is the thread safe queue module, which is "annoyingly
> execution-order-dependent because it has to operate safely as interrupt
> code potentially interrupting itself").
>
> Dan would like a version of Configure.pl which can build a makefile (or
> whatever build tool we end up using) with per-C-file compiler flags, and
> it needs to be possible to override those flags, per file, by the
> platform configuration module.

Hmm, I'm only a lurker, 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
--

[Rafael Garcia-Suarez]

Alan Burlison wrote in perl.perl6.internals :

That doesn't make this per-C-file-cc-option-tweaking necessarily
unuseful. Perl 5 uses something similar, because the lexer is sometimes
miscompiled when some compilers with a high optimization level. Example :
see the hints files and lookup "XXX_cflags" or "toke_cflags" in
hints/README.hints.

[Alan Burlison]

Rafael Garcia-Suarez wrote:

>>Hmm, I'm only a lurker, 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?
>
> That doesn't make this per-C-file-cc-option-tweaking necessarily
> unuseful. Perl 5 uses something similar, because the lexer is sometimes
> miscompiled when some compilers with a high optimization level. Example :
> see the hints files and lookup "XXX_cflags" or "toke_cflags" in
> hints/README.hints.

I'm not saying it isn't useful - per compiler workarounds for brokenness is
one thing, but the implication was that this tweakage was needed for *all*
compilers for those particular files, which spells 'broken' in my book. If
the code makes 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
--

[K Stol]

This is taken from this week's summary, but I thought this post would fit
best in this thread.

>
> Tentative valclone patch
> Luke Palmer has been thinking about value and reference objects. He
> wondered if there was any value in a "valclone" operator alongside
"set"
> and "clone" which would allow the target PMC to decide whether to use
> "set" or "clone" semantics. He also offered a patch implementing the
> operator if people thought it would be useful. Leo Tötsch wasn't sure
> the new operator was necessary.
>
> Klaas-jan Stol noted that he'd encountered problems with
reference/value
> confusion when he'd been working on his Lua compiler, but he wondered
if
> the problem couldn't be solved by having a general, language
independent
> "argument" PMC class. (I'm not sure I understood what he meant by this
> so I'm hoping for an explanation with code fragments).
>

> --
> Piers
>

Piers,

I heard your call :-) Here goes...

Maybe it isn't possible what I'd like, but here's what I was thinking of.

I don't know Perl that well, and to keep things readable for everybody,
let's suppose we have the following routine in some (non-existent) language:

subroutine foo(x, y)
{
// do stuff
}

.sub _foo
.param Argument x
.param Argument y
# do stuff
ret
.end

Now, when foo is called with arguments which are references to things
("objects"), then only the reference must be copied into the argument
variables.
However, when the arguments are more 'basic' types like integers or
whatever, some languages may require that these are passed by value! When
these 'basic' types are implemented as PMCs (which is likely in dyn. typed
languages), then the PMC REFERENCE is copied, because that's the default for
PMCs.

to clearify:

P0 = new PerlInt
P1 = new PerlInt
P0 = 123
P1 = P0 # now P1 is referencing the PerlInt in P0; changing the object
from P1 will affect the PMC referenced # by P0.
inc P1
print P0 # will print "124" !

In Perl, this is the default behaviour (for what I understood): everything
is passed by reference. However there are languages (well, there MAY be) in
which the 'basic' types are passed by value.
In these cases, we'd need a _clone_ instruction. This would result in:

.sub _foo
.local PerlUndef x
.local PerlUndef y

# now using pseude code, for ease of reading:

#Parameter x:
if actual type of x is a 'basic' type, then
x = clone P5 # P5 is first argument, see PDD for calling conv.
else
x = P5

#Parameter y:
if actual type of y is a 'basic' type, then
y = clone P6 # don't copy reference, but copy whole of object
else
y = P6 # y will reference same object as P6

#do stuff
ret
.end

Obviously, this is not very clean, not to mention fast. So it would be nice
to stuff this run-time check into some PMC.
At this very moment I realize that it's not really a matter of some PMC type
for arguments, but that it's a matter of adding a operation for PMCs:
something like a "pass_as_argument" operation: the PMC knows what to do:
clone or copy. (now raises the question: is this worth it?)

I know Perl don't has this problem, but there may be languages that do have
this problem (and I can mention at least 1 :-). It would be kinda nice if
Parrot can easily handle this as well, but that's not up to me to decide of
course.

Klaas-Jan

[K Stol]

[Dan Sugalski]

Unfortunately given what the code does we can't use mutexes, since
they're not interrupt-safe, which I'm not particularly happy about.
The queues in question are thread-specific, though, which takes some
of the danger out of things. I fully expect to have to do more work
than just disabling optimizations to disable reordering to make this
function right everywhere. (I know, I know, platform-independent
interrupt code is just not doable, but...)

Personally, I'd much prefer to use platform-provided interrupt-safe
queueing mechanisms, and we will in those places where it's
available. I know it *is* available on VMS, and *isn't* available on
OS X and Linux. I'm also very painfully aware of some of the issues
that need to be dealt with for processors with internal read and
write reordering, which isn't anywhere near fun to deal with. (Well,
OK, it is, but I'm weird that way)

What I'd really like is a nice, portable, insqti/remqhi
implementation, but barring that (since I'm not going to get it)
something as close as possible.
--
Dan

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

[Gordon Henriksen]

Shouldn't Perl make this determination at compile time based upon the
subroutine's signature? Doesn't seem to me that it is in any way a
decision for the assembler.

—

Gordon Henriksen
mali...@mac.com

[K Stol]

In Perl this is possible (because of the syntax of Perl). But what about languages in which it cannot be expressed?
I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't it be nice to have Parrot supporting this?

klaas-jan

[Alan Burlison]

Dan Sugalski wrote:

> Unfortunately given what the code does we can't use mutexes, since
> they're not interrupt-safe, which I'm not particularly happy about. The
> queues in question are thread-specific, though, which takes some of the
> danger out of things. I fully expect to have to do more work than just
> disabling optimizations to disable reordering to make this function
> right everywhere. (I know, I know, platform-independent interrupt code
> is just not doable, but...)

Hmm, I don't think the issue is that mutexes aren't interrupt-safe, I think
the issue is that if an interrupt routine is reentered it may already be
holding a mutex and therefore self-deadlock. The Solaris attributes(5)
manpage says this about Async-Signal-Safe routines (which I believe is what
you are trying to do):

Async-Signal-Safe
Async-Signal-Safe refers to particular library rou-
tines that can be safely called from a signal handler.
A thread that is executing an Async-Signal-Safe rou-
tine will not deadlock with itself if interrupted by a
signal. Signals are only a problem for MT-Safe rou-
tines that acquire locks.

Signals are disabled when locks are acquired in
Async-Signal-Safe routines. This prevents a signal
handler that might acquire the same lock from being
called.

> Personally, I'd much prefer to use platform-provided interrupt-safe
> queueing mechanisms, and we will in those places where it's available. I
> know it *is* available on VMS, and *isn't* available on OS X and Linux.
> I'm also very painfully aware of some of the issues that need to be
> dealt with for processors with internal read and write reordering, which
> isn't anywhere near fun to deal with. (Well, OK, it is, but I'm weird
> that way)
>
> What I'd really like is a nice, portable, insqti/remqhi implementation,
> but barring that (since I'm not going to get it) something as close as
> possible.

I suggest you disable signals during the queue operations, take out the
lock, do the work, drop the lock then reenable signals.

--
Alan Burlison
--

[Uri Guttman]

>>>>> "AB" == Alan Burlison <Alan.B...@sun.com> writes:

AB> I suggest you disable signals during the queue operations, take
AB> out the lock, do the work, drop the lock then reenable signals.

that is just how the kernel does interrupt handling. i did the same in
an rtos eons ago. drivers could do queue stuff safely because they first
disabled interrupts and reenabled them when done. sounds like a good
plan and doable in user space with signal stuff. sigblock and sigsetmask
seem to the the calls to use. dunno if they are on windows but i don't
think they have proper signals at all.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

[Dan Sugalski]

At 4:01 PM +0100 7/2/03, Alan Burlison wrote:
>Dan Sugalski wrote:
>
>>Unfortunately given what the code does we can't use mutexes, since
>>they're not interrupt-safe, which I'm not particularly happy about.
>>The queues in question are thread-specific, though, which takes
>>some of the danger out of things. I fully expect to have to do more
>>work than just disabling optimizations to disable reordering to
>>make this function right everywhere. (I know, I know,
>>platform-independent interrupt code is just not doable, but...)
>
>Hmm, I don't think the issue is that mutexes aren't interrupt-safe,
>I think the issue is that if an interrupt routine is reentered it
>may already be holding a mutex and therefore self-deadlock.

I'm pretty sure the POSIX docs say that you can't call mutex routines
from within interrupt code, which makes sense--the last thing you
want is for an interrupt handler to block on a mutex aquisition.

This isn't actually a big deal, as it's reasonably straightforward to
write code that can handle multiple user-space readers and writers
(which can guard themselves with mutexes) and a single interrupt-time
writer. Proper ordering and checking of operations inside the code
makes this straightforward, if a pain. (And I know the ordering's
doable, otherwise every single OS on the planet with interrupt code
would fall down and go boom :) The nasty part comes in with multiple
interrupt-time writers. I'm not sure if it's common to be able to
have multiple concurrent interrupt handlers running, but I do know
it's possible.

I'd considered just up and disabling interrupts entirely but I didn't
want to take the performance hit from it. I'm thinking now that
decision was a bad one, but luckily one that's not welded into
anything anywhere (and wouldn't have been even if I'd kept going this
way, as all we would've guaranteed is thread-safe interrupt-safe
queues) so it's simple enough to change.

Disabling signals and interrupts is still going to be
platform-specific, but that's not a big deal.

[Alan Burlison]

Dan Sugalski wrote:

> I'm pretty sure the POSIX docs say that you can't call mutex routines
> from within interrupt code, which makes sense--the last thing you want
> is for an interrupt handler to block on a mutex aquisition.

I haven't got a copy, but I'd be surprised if they explicitly forbade it - I
think however you *do* need to be very careful if you need to mix mutexes
and signals, so that you don't self-deadlock.

> This isn't actually a big deal, as it's reasonably straightforward to
> write code that can handle multiple user-space readers and writers
> (which can guard themselves with mutexes) and a single interrupt-time
> writer. Proper ordering and checking of operations inside the code makes
> this straightforward, if a pain. (And I know the ordering's doable,
> otherwise every single OS on the planet with interrupt code would fall
> down and go boom :) The nasty part comes in with multiple interrupt-time
> writers. I'm not sure if it's common to be able to have multiple
> concurrent interrupt handlers running, but I do know it's possible.

You *cannot* achieve what you want by 'proper ordering and checking of
operations', as this will *not* work on a SMP machine, where the ordering of
loads and stores is *not* guaranteed, *irrespective* of what appears to be
the order of instructions produced by the compiler. To achieve what you
want you need a memory barrier, which is other thing a mutex provides in
addition to synchronization. For details, see either section 3.4 "Memory
visibility between threads" in "Programming with Posix Threads" by David
Butenhof, or follow the links below:

http://www.math.cmu.edu/Parallel_Cluster/smp/Lthreadsfaq.htm#Q118
http://www.math.cmu.edu/Parallel_Cluster/smp/Lthreadsfaq.htm#Q156
http://www.math.cmu.edu/Parallel_Cluster/smp/Lthreadsfaq.htm#Q162
http://www.math.cmu.edu/Parallel_Cluster/smp/Lthreadsfaq.htm#Q180
http://www.math.cmu.edu/Parallel_Cluster/smp/Lthreadsfaq.htm#Q202

> I'd considered just up and disabling interrupts entirely but I didn't
> want to take the performance hit from it. I'm thinking now that decision
> was a bad one, but luckily one that's not welded into anything anywhere
> (and wouldn't have been even if I'd kept going this way, as all we
> would've guaranteed is thread-safe interrupt-safe queues) so it's simple
> enough to change.
>
> Disabling signals and interrupts is still going to be platform-specific,
> but that's not a big deal.

I think that what you are trying to do is ensure that the queue operations
are async-signal safe - here is what our threads expert has to say about this:

| For a function to be async-signal safe (that is, to be callable both
| at main level and from a signal handler) it has to block all signals
| before acquiring any locks (including any locks acquired by any
| library functions it calls). Otherwise, it could grab a lock at main
| level, take a signal, and attempt to acquire the same lock at
| interrupt level, thereby deadlocking itself.
|
| And, no, recursive locks are not the answer; all that would do is
| invite data corruption: the lock is being held because the data
| invariants are being modified; allowing a signal handler 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
--

[Dan Sugalski]

At 8:11 AM +0100 7/3/03, Alan Burlison wrote:
>Dan Sugalski wrote:
>
>>I'm pretty sure the POSIX docs say that you can't call mutex
>>routines from within interrupt code, which makes sense--the last
>>thing you want is for an interrupt handler to block on a mutex
>>aquisition.
>
>I haven't got a copy, but I'd be surprised if they explicitly
>forbade it - I think however you *do* need to be very careful if you
>need to mix mutexes and signals, so that you don't self-deadlock.

I don't have a copy handy anymore either, unfortunately, but
Butenhof's pretty clear--none of the Posix thread functions are async
safe. (Section 6.6.6, p234-235 in my copy) I seem to remember someone
scolding me about this, or something like it, ages ago.

Even in those cases where the posix stuff is OK in signal handlers
it's still not enough, as the world isn't entirely unix, and on most
of those platforms where this sort of thing is actively useful
(Basically systems with async I/O and per-request callbacks) signals
aren't used for this sort of thing. Most Unix systems will probably
have us falling back to synchronous I/O and I/O threads. It's the
Windows (and, to a lesser extent, VMS systems) that get dealt with
there, and I'm pretty sure you're not allowed to do any sort of
pthreads stuff in their AST routines.

To make this work right without the benefits of locks is going to
require proper code ordering, memory barriers, and thread wakeup from
interrupt routines. I'm not 100% sure that it's worth it at this
point, given how much of a major, platform-dependent pain it'll be.
(The whole darned code segment in question will have every other line
a PLATFORM_MEMORY_BARRIER macro) I'm half tempted to just punt it
into the platform-specific source module, but that has its own issues.

>>This isn't actually a big deal, as it's reasonably straightforward
>>to write code that can handle multiple user-space readers and
>>writers (which can guard themselves with mutexes) and a single
>>interrupt-time writer. Proper ordering and checking of operations
>>inside the code makes this straightforward, if a pain. (And I know
>>the ordering's doable, otherwise every single OS on the planet with
>>interrupt code would fall down and go boom :) The nasty part comes
>>in with multiple interrupt-time writers. I'm not sure if it's
>>common to be able to have multiple concurrent interrupt handlers
>>running, but I do know it's possible.
>
>You *cannot* achieve what you want by 'proper ordering and checking
>of operations', as this will *not* work on a SMP machine, where the
>ordering of loads and stores is *not* guaranteed, *irrespective* of
>what appears to be the order of instructions produced by the
>compiler.

Right, I understand that. (My processor of choice is the Alpha -- I'm
altogether too familiar with the fun that SMP and out-of-order
execution and loads/stores bring) Maintaining a single user-mode
reader or writer is simple and, with that caveat, having a single
interrupt-level writer becomes, while not trivial, reasonably doable.
I realized after I started all this that I could potentially have
multiple interrupt-level writers going simultaneously, which makes
things rather more difficult, though I think that's only possible so
far on recent VMS systems, and is disableable. (And while I could
block interrupts from within the interrupt handler, there's still the
small but non-zero chance that two interrupts are being serviced
essentially simultaneously such that disabling interrupts won't
matter since I've two in flight at once.

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.

[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
--

[Uri Guttman]

>>>>> "AB" == Alan Burlison <Alan.B...@sun.com> writes:

AB> 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.

AB> Agreed. Glug, glug, glug.... ;-)

who here will be at oscon (or yapc::eu)? i would like to get a small BOF
going on this subject. i agree it is a morass but i have some ideas and
i know dan has plenty. but we had better learn to swim these swamps and
not get eaten by the gators. we can drain them, convert them to dry
deserts and make them safe for camel caravans. :)

thanx,

[Alan Burlison]

Uri Guttman wrote:

> who here will be at oscon (or yapc::eu)? i would like to get a small BOF
> going on this subject. i agree it is a morass but i have some ideas and
> i know dan has plenty. but we had better learn to swim these swamps and
> not get eaten by the gators. we can drain them, convert them to dry
> deserts and make them safe for camel caravans. :)

I'll be at yapc::eu

--
Alan Burlison
--

[Tim Bunce]

On Thu, Jul 03, 2003 at 05:10:23PM -0400, Uri Guttman wrote:
> >>>>> "AB" == Alan Burlison <Alan.B...@sun.com> writes:
>
> AB> 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.
>
> AB> Agreed. Glug, glug, glug.... ;-)
>
> who here will be at oscon (or yapc::eu)? i would like to get a small BOF
> going on this subject. i agree it is a morass but i have some ideas and
> i know dan has plenty. but we had better learn to swim these swamps and
> not get eaten by the gators. we can drain them, convert them to dry
> deserts and make them safe for camel caravans. :)

Has any other language learnt to swim well in these swamps?

Tim.

[Stéphane Payrard]

Brian Ingerson and Éric Cholet have kindly set up a k?wiki for yapc::eu.
There will be a BOF Saturday July 26 starting a 10 pm and probably
running until 13pm.

I have created an entry for the Parrot BOF.
It's up to you to add material, like the issues you want to
be discussed.

http://yapc.eu.kwiki.org/index.cgi?ParrotBOF

--
stef

[Uri Guttman]

>>>>> "TB" == Tim Bunce <Tim....@pobox.com> writes:

TB> Has any other language learnt to swim well in these swamps?

none that i have heard of can swim all swamps. we could be pioneers
here! they may name some swamp after parrot!

[Tom Hughes]

In message <a05210601bb2a25b99100@[192.168.0.78]>
Dan Sugalski <d...@sidhe.org> wrote:

> At 8:11 AM +0100 7/3/03, Alan Burlison wrote:
> >Dan Sugalski wrote:
> >
> >>I'm pretty sure the POSIX docs say that you can't call mutex
> >>routines from within interrupt code, which makes sense--the last
> >>thing you want is for an interrupt handler to block on a mutex
> >>aquisition.
> >
> >I haven't got a copy, but I'd be surprised if they explicitly
> >forbade it - I think however you *do* need to be very careful if you
> >need to mix mutexes and signals, so that you don't self-deadlock.
>
> I don't have a copy handy anymore either, unfortunately, but
> Butenhof's pretty clear--none of the Posix thread functions are async
> safe. (Section 6.6.6, p234-235 in my copy) I seem to remember someone
> scolding me about this, or something like it, ages ago.

The POSIX docs (or rather their successor, the SuS docs) can be
found online - the current version is at:

http://www.opengroup.org/onlinepubs/007904975/toc.htm

Specific documentation the the pthread routines is at:

http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html

Tom

--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/

[Dan Sugalski]

Cross-platform? Not that I know of. On single platforms, sure. That's
easy. Well, relatively easy, at least.

[Dan Sugalski]

At 6:17 PM -0400 7/3/03, Uri Guttman wrote:
> >>>>> "TB" == Tim Bunce <Tim....@pobox.com> writes:
>
> TB> On Thu, Jul 03, 2003 at 05:10:23PM -0400, Uri Guttman wrote:
> >> >>>>> "AB" == Alan Burlison <Alan.B...@sun.com> writes:
> >>
> AB> 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.
> >>
> AB> Agreed. Glug, glug, glug.... ;-)
> >> who here will be at oscon (or yapc::eu)? i would like to get a
> >> small BOF going on this subject. i agree it is a morass but i have
> >> some ideas and i know dan has plenty. but we had better learn to
> >> swim these swamps and not get eaten by the gators. we can drain
> >> them, convert them to dry deserts and make them safe for camel
> >> caravans. :)
>
> TB> Has any other language learnt to swim well in these swamps?
>
>none that i have heard of can swim all swamps. we could be pioneers
>here! they may name some swamp after parrot!

Or we could burn down, fall over, then sink into the swamp. You never
know... :)

[Uri Guttman]

>>>>> "SP" == Stéphane Payrard <st...@payrard.net> writes:

SP> Brian Ingerson and Éric Cholet have kindly set up a k?wiki for
SP> yapc::eu. There will be a BOF Saturday July 26 starting a 10 pm
SP> and probably running until 13pm.

hmm, that is probably a tourist day for my wife and i. we could just do
a bof during lunch one day. also i assume you mean 10am above. :)

SP> I have created an entry for the Parrot BOF. It's up to you to add
SP> material, like the issues you want to be discussed.

SP> http://yapc.eu.kwiki.org/index.cgi?ParrotBOF

i updated that to add an async i/o bof at lunchtime on wednesday.
contact me or email p6i if you want to be in this bof. we can pick a
local cafe or bistro near CNAM to meet.

a bof at oscon will also be useful as not many will be going to both.

[Stéphane Payrard]

Bcc:
Subject: Re: yapc::eu Parrot BOF
Reply-To: st...@payrard.net
In-Reply-To: <a05210609bb2a5de6bc45@[192.168.0.78]>

On Thu, Jul 03, 2003 at 06:26:10PM -0400, Dan Sugalski wrote:
> At 12:12 AM +0200 7/4/03, Stéphane Payrard wrote:
> >Brian Ingerson and Éric Cholet have kindly set up a k?wiki for yapc::eu.
> >There will be a BOF Saturday July 26 starting a 10 pm and probably
> >running until 13pm.
>
> 10 PM or 10 AM? (Or is this metric time? :)

I was confused.
I meant 10 o'clock in the morning to 1 in the afternoon.
I think I got it right in the wiki page.

I don't think the metric system has proposed to go "decimal" for the
time and we have long forsaken the revolutionary calendar. :)

That reminds me, I need to pack and submit my ACME::Bibi which is an alternative
to the hexadecimal notation that use syllables in place of '0'..'9' 'A'..'Z'

http://worldserver2.oleane.com/fatrazie/Bibi.html

--
stef

[Uri Guttman]

>>>>> "DS" == Dan Sugalski <d...@sidhe.org> writes:

DS> At 6:17 PM -0400 7/3/03, Uri Guttman wrote:
>> >>>>> "TB" == Tim Bunce <Tim....@pobox.com> writes:

TB> Has any other language learnt to swim well in these swamps?
>> none that i have heard of can swim all swamps. we could be
>> pioneers here! they may name some swamp after parrot!

DS> Or we could burn down, fall over, then sink into the swamp. You
DS> never know... :) -- Dan

but someday, all of this could be OURS!

just imagine, the cross platform async i/o threaded world will be
exclusive to parrot. we can patent it, charge millions for license fees
and take over the world!! MUAHAHAHAHAHAH!

[Dan Sugalski]

At 9:13 AM +0200 7/2/03, K Stol wrote:
>In Perl this is possible (because of the syntax of Perl). But what
>about languages in which it cannot be expressed?
>I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't
>it be nice to have Parrot supporting this?

Yup, it would. Parrot's assuming pass-by-reference for reference
types (Strings and PMCs) and pass-by-value for value types (ints and
nums). I'm tempted to leave it like that so there's a level of
constancy there, and let the languages that want to take parameters
in by value rather than reference make a copy of what's passed in.

Real reference types, the way objects are traditionally handled,
won't change in this sort of scheme (as we'd just copy the reference)
but that's normally the way things are supposed to happen.

This, of course, brings up the question of who gets to decide whether
things are passed by value or reference, the caller or callee, so I'm
up for discussion on that.

> ----- Original Message -----
> From: Gordon Henriksen
> To: K Stol
> Cc: perl6-i...@perl.org
> Sent: Wednesday, July 02, 2003 6:12 AM
> Subject: Re: Tentative [PATCH]: valclone
>
>
> Shouldn't Perl make this determination at compile time based upon
>the subroutine's signature? Doesn't seem to me that it is in any way
>a decision for the assembler.

[K Stol]

----- Original Message -----
From: "Dan Sugalski" <d...@sidhe.org>
To: "K Stol" <joei...@home.nl>; "Gordon Henriksen" <mali...@mac.com>
Cc: <perl6-i...@perl.org>
Sent: Friday, July 04, 2003 4:56 PM
Subject: Re: Tentative [PATCH]: valclone

> At 9:13 AM +0200 7/2/03, K Stol wrote:
> >In Perl this is possible (because of the syntax of Perl). But what
> >about languages in which it cannot be expressed?
> >I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't
> >it be nice to have Parrot supporting this?
>
> Yup, it would. Parrot's assuming pass-by-reference for reference
> types (Strings and PMCs) and pass-by-value for value types (ints and
> nums). I'm tempted to leave it like that so there's a level of
> constancy there, and let the languages that want to take parameters
> in by value rather than reference make a copy of what's passed in.
>

So, you agree it would be nice for Parrot to have an option to pass PMCs
(and maybe strings as well) by value, as well as the standard by reference,
right? If so, there should be some *fast* way of doing this (of course, this
is already possible using the current instructions, but it should be
*fast*), so maybe a special instruction for that?

> Real reference types, the way objects are traditionally handled,
> won't change in this sort of scheme (as we'd just copy the reference)
> but that's normally the way things are supposed to happen.
>
> This, of course, brings up the question of who gets to decide whether
> things are passed by value or reference, the caller or callee, so I'm
> up for discussion on that.

Well, this is my try...

Good point. At first I didn't really think this through too well. My first
idea was this:
The callee copies the passed-in PMCs, so the callee would be responsible. In
this case, the caller isn't really sure if the passed-in PMCs are still
valid after the function call: the called function could have changed them,
or even destroyed them (if the callee was compiled to handle the params. by
reference) (But this really isn't an issue, because the compiler will emit
the right instructions, but it's just a thought).

On the other hand, it would be quite ok if the callee doesn't really care
which PMCs it receives, it just does its job (and it doesn't really care if
the args are copies or the 'original' PMCs), and it depends on the compiler
for emitting the right code (so it will spit out by-value instructions). (so
the caller is responsible).

Would there be a performance difference? I think not, but I could well be
wrong (anybody?).

klaas-jan

[Leopold Toetsch]

K Stol <k_s...@hotmail.com> wrote:
> ----- Original Message -----
> From: "Dan Sugalski" <d...@sidhe.org>
>>

>> This, of course, brings up the question of who gets to decide whether
>> things are passed by value or reference, the caller or callee, so I'm
>> up for discussion on that.

> The callee copies the passed-in PMCs, so the callee would be responsible. In

> this case, the caller isn't really sure if the passed-in PMCs are still
> valid after the function call:

If we are inside one language, that is all up to the compiler. You don't
have that at subroutine calls only, but on each assignment statement:

set P0, P1
set I0, I1

are very different instructions.
This is a compiler problem to emit a correct sequence of
set/assign/clone or something.

The real fun comes, when one language calls a sub/method of another one.
The proposed intermediate param class can't help here. Its a matter of
interface definitions - and that is fixed (IMHO) by the function
providing the interface or functionality

> klaas-jan

leo

[Gordon Henriksen]

On Friday, July 4, 2003, at 10:56 , Dan Sugalski wrote:

> This, of course, brings up the question of who gets to decide whether
> things are passed by value or reference, the caller or callee, so I'm
> up for discussion on that.

Isn't this again a function of the routine's signature? The callee ought
to indicate whether it wishes a reference or not, and the caller in turn
must be bound to conform to that contract. So my answer to this question
would be that both are responsible for conforming to the signature
dictated by the called routine. Admittedly not in keeping with Perl 5
(aliased @_), but in keeping with the Apocalypses: Perl 6 arguments will
be passed by value unless is rw is specified, meaning that the prototype
must be examined, either at run- or compile-time, in order to make the
decision.

The alternative: Pass all parameters by reference all the time and have
the callee make copies when it wants a by-value parameter. Optimizer
hell. Probably bad for locality of reference. Potentially good for
performance if the average argument is larger than a pointer type,
though.

—

Gordon Henriksen
mali...@mac.com