Jack Jansen wrote:
>
> On zondag, mei 26, 2002, at 11:49 , Christian Tismer wrote:
[Tcl w. STackless probs]
> Does your assertion "it works great with PythonWin and wxPython" mean
> that neither of those can have the situation where you go from Python ->
> Windows -> Python -> Windows (or replace Windows with wx) while you have
> a reference to the first Python stack passed to the first Windows call,
> which is then subsequently used by the second Windows call? Or does it
> mean something "lighter"?
AFAICT, neither wx, nor PyWin do put anything on the
stack between Python calls. For PythonWin, I'm pretty
sure since otherwise the olde stackless would have blocked
multitasking, which it didn't. It blocked on every real
interpreter recursion which was not avoidable. There
was so such thing. For that reason, I was happily
implementing the current scheme, assuming this to be
a general rule. Well, I remember that in Idle, I had
to start scheduling *after* all GUI stuff had been loaded,
so I should have been warned.
With wx, I'm not yet completely sure. What I used was the
interactive shell of the Boa constructor environment.
This implementation appears to be super-clean. My tasklets
run in the GUI shell, and if some are left, they will
run after destruction of the GUI, in the DOS window, as
if nothing happened.
But I didn't try my own wxPython apps, yet, and for sure
I will need to do some locking stuff, but hopefully
not tricking thes stack-lockups.
> Because if you indeed mean what I guess here then I can't be sure that
> the Mac toolbox modules are safe either, at least not without serious
> inspection. A lot of structures are allocated on the stack in the glue
> routines, and a lot of toolbox modules may do callbacks.
Bad news, makes me nervous. I see myself building kind
of registry of contexts which are forbidden to switch.
Structure which are kept on the stack as globals during
the lifetime of some calls, even through a sequence of
multiple python calls, really give me a headache.
On the other hand: The old stackess worked fine
with Just's Mac IDE. If there were callbacks through
C code, this stackless again would have blocked. That
means, although such situations do exist as you say,
they are atomic, and blocking is the right way.
I think I should think my design over and provide
restrictive blocking by default, together with
a table of function calls which are known to be
safely switched.
That means to me that I have to do a full stack
analysis for every platform. I started to do this
anyway, since I'm quite near to pickleable threads,
but I wasn't aware that I have to go this path
so early...
Au Backe!
> Or does your "works great" merely mean that you haven't run into any
> problems yet?
As said, it works well, but I didn't do all necessary
exhaustive testing yet. I'd love to test it on a Mac,
but still the PowerPC implementation is incomplete
and I can't get at it before I have access to such a
machine (maybe in two weeks).
ciao - chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4