Weird pointer errors... Stackless problem? PyString_InternInPlace Fatal error
Christian Tismer
tismer at appliedbiometrics.com
Mon Sep 18 04:18:54 EDT 2000
Mike Fletcher wrote:
>
> Hmm, by that description (assuming I understood it, I got lost somewhere in
> there), the uthread lock should be fine... i.e. if the lock-state is stored
> in the continuation (which you seem to say it is), then it is restored when
> the continuation is called (the thread is woken up). The finally clause
> around atomic should be altering a different frame than the one encoded in
> the continuation... I think...
The lock is not in the continuation.
The lock is in the thread_state of your system thread.
> Note, it's not a try-except clause (at least, not in uthread9), it's a
> try-finally. My code has try-except clauses, should I try removing those
> (difficult, but I might be able to try it in a week).
No, not removing, but make them specific to the exceptions
which you expect, and let others make it through.
NOTE!: The lock flag is also cleared automatically if the
scheduler is run. So, regardless of the lock state:
Whenever a task is run by the scheduler, then there is no lock.
> Urgh. Really not sure here, and not enough time to play. I've got a
> deadline in two days, so I'll likely just try to back out my work until I
> find something that doesn't trigger the error (looks like a few weeks so far
> <eeps!>).
Why don't you just give me a copy of your code?
ciao - chris
--
Christian Tismer :^) <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
More information about the Python-list
mailing list