Nick Maclaren wrote:
The compiled code has made a data structure temporarily inconsistent
because the operation is safe (say, list insertion), and then gets an
asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some
operation (e.g. I/O) that implicitly uses floating-point, which
Greg Ewing
And all of this is getting rather far away from where we
started, which was simply instrumenting a piece of code
to count floating point exceptions.
I'm thinking of adding a note to the Py2.5 docs that the counting feature is
not
part of the standard and should not be expected to
2006/7/26, Raymond Hettinger [EMAIL PROTECTED]:
Greg Ewing
And all of this is getting rather far away from where we
started, which was simply instrumenting a piece of code
to count floating point exceptions.
I'm thinking of adding a note to the Py2.5 docs that the counting feature is
Greg Ewing [EMAIL PROTECTED] wrote:
But we weren't talking about asynchronous exceptions,
we were talking about floating point exceptions. Unless
your TLB miss handler uses floating point arithmethic,
there's no way it can get interrupted by one. (And if
it does use floating point
James Y Knight [EMAIL PROTECTED] wrote:
To cut a long story short, it is impractical for a language run-time
system to call user-defined handlers with any degree of reliability
unless the compiled code and run-time interoperate carefully - I have
been there and done that many times, but
Greg Ewing [EMAIL PROTECTED] wrote:
Now, interrupting into that level has to be transparent, in order to
support TLB misses, clock interrupts, device interrupts, machine-check
interrupts and so on.
I thought we were just talking about counting the number
of floating point exceptions
On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote:
To cut a long story short, it is impractical for a language run-time
system to call user-defined handlers with any degree of reliability
unless the compiled code and run-time interoperate carefully - I have
been there and done that many times,
Greg Ewing [EMAIL PROTECTED] wrote:
But couldn't you just put in an interrupt handler that
counts the interrupts, for the purpose of measurement?
No, but the reasons are very arcane.
The general reason is that taking an interrupt handler and returning
is not transparent, and is often not
Nick Maclaren wrote:
Now, interrupting into that level has to be transparent, in order to
support TLB misses, clock interrupts, device interrupts, machine-check
interrupts and so on.
I thought we were just talking about counting the number
of floating point exceptions that a particular piece
Raymond Hettinger wrote:
Aahz wrote:
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to
Georg Brandl wrote:
Raymond Hettinger wrote:
If the current approach
gets in their way, the C implementers should feel free to make an
alternate design choice.
+1. (cDecimal is an ugly name, but a sound concept)
I don't know what progress Mateusz' work has made until now, but he wrote
I think it was tripping-up the folks working on the C implementation.
Georg can speak to it more directly. IIRC, the issue was that the
context object exposed a dictionary which a user could update directly
and there was no notification back to the surrounding object so it could
Georg Brandl [EMAIL PROTECTED] wrote:
Even then, we need to drop the concept of having the flags as counters
rather than booleans.
Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.
Well, I can. There is a traditional, important use -
...
[Raymond]
Even then, we need to drop the concept of having the flags as counters
rather than booleans.
[Georg Brandl]
Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.
That's not it -- someone will find a use for anything. It's
Nick Maclaren wrote:
When such arithmetic is implemented in hardware, it is normal for
exceptional cases to be handled by interrupt, and that is VERY
expensive ... It then becomes important to know how
many of the things you got, to know whether it is worth putting
code in to avoid them or
Tim Peters wrote:
...
[Raymond]
Even then, we need to drop the concept of having the flags as counters
rather than booleans.
[Georg Brandl]
Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.
I briefly had a chance to look at some of the work being done on a C
implementation of decimal, and it looks like the approach is following
the Python version too literally.
Ideally, it should be written as if Python were not involved and
afterwards add the appropriate method wrappers.
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to me that making a
small wrapper for dict access
[Raymond Hettinger]
...
If the current approach gets in their way, the C implementers should feel
free to
make an alternate design choice.
I expect they will, eventually. Converting this to C is a big job,
and at the NFS sprint we settled on an incremental strategy allowing
most of the
Aahz wrote:
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to me that making
On 7/18/06, Tim Peters [EMAIL PROTECTED] wrote:
[Raymond Hettinger]
...
If the current approach gets in their way, the C implementers should feel
free to
make an alternate design choice.
I expect they will, eventually. Converting this to C is a big job,
and at the NFS sprint we
Lisandro Dalcin wrote:
On 7/18/06, Tim Peters [EMAIL PROTECTED] wrote:
[Raymond Hettinger]
...
If the current approach gets in their way, the C implementers should feel free to
make an alternate design choice.
I expect they will, eventually.
Tim Peters wrote:
Changing the user-visible API is a hard egg to
swallow, and it's unfortunate that the Python code used a dict to hold
flags to begin with. The dict doesn't just record whether an
exception has occurred, it also counts how many times the exception
occurred. It's possible
23 matches
Mail list logo
