I’ve just fixed a bug where the data sent over a channel could get lost, being replaced with a “None”.
This could happen if channel action, tasklet deletion and stack spilling all happened at once J
See
http://blog.ccpgames.com/kristjan/
for details.
K
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
Hello, I'm wondering how tasklets can clean themselves up when they are destroyed due to garbage collection (i.e. when they are not in the runnables and not referenced by any object anymore). Greenlet solves this problem by raising a GreenletExit exception in the greenlet's run function when the greenlet is about to die due to garbage collection. However, in stackless, it seems that no TaskletExit exception is raised when the tasklet is about to die, so we can't simply use a try/finally in the tasklet's callable to clean up resources. I tried to wrap my tasklet in a parent object which has the same lifespan as my tasklet and has a __del__ function for cleaning up, but I keep having problems with circular references (the wrapper/parent object also provides the callable of the tasklet, i.e. a bound method) that make the tasklet/parent object uncollectable (circular references : wrapper --> tasklet --> stackless machinery? --> callable stack frame (bound method of wrapper) --> wrapper). Same problem when trying to inherit from tasklet. So, how can I clean up resources in tasklets? (I'm pretty sure I've missed something obvious) Thank in advance, Sylvain -- -- Sylvain PRAT
I wondered if anybody here has used Stackless Python in some clever ways to work around the global interpreter lock. I have some C++ objects wrapped with Boost.Python, and I run into some interesting stuff when I start implementing interfaces defined in these wrappers in Python. At that point I have to do some work that involves acquiring the GIL to run the Python version of the code whenever I'm running into it from the C++ side in other threads. This normally works okay until I get into situations like this:
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
Hello, I'm not sure if this has sense but I'm wondering if Stackless 'clean ups' all tasklet resources when tasklets die. For example, suposse a tasklet that opens files and/or sockets, will those resources be automatically closed when the tasklet die? Can that be done easily? Thanks in advance.
So,
Channels objey the iterator protocol. calling channel.close() will raise the StopIteration exception from the channel.__next__ method.
But, calling channel.close() from the receiving end will also cause this same exception to be raised when someone wants to call channel.send().
Now, I wonder if a more appropriate exception for the send() call wouldn‘t be GeneratorExit()? This is what the generator yield(foo) statement raises when the generator is closed, and it seems logical that this should be the exception raised when someone tries to send to a closed channel.
K
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
Here is a fix for the exception handler, I included just the .patch.
This corrects the problems with python having a different exception the environment when the item is called again.
In the previous code, whenever a python tasklet was suspended the top
of the exception chain was saved. This very well could be a pointer into
code above the python stack into the main program. When the python
tasklet is called again, it's stack is put back *in the same place*, but
the environment above the stack *might be different*. This would cause
the exception chain to screw up in the part where the exception chain
points above the stack. This was the cause of the broken exception chain
bug.
If a tasklet has none of it's own exception
chains, we will discover this by reading the exception list and seeing
that the address is above the stack, so we don't need to save or restore
it it.
If, on the other hand, the tasklet has a chain we save it.
When restoring it we look at the current chain and insert the chain from
the restored stack into it at the appropriate spot, so that the
tasklet's chain points correctly into it's parent's change.
Stack slicing: Stackless in general has a problem with stack
slicing. This code will work in when the stack is sliced (I tested it
with 2K stack slices and try-catches everywhere) but certain exceptions
that belonged to inactive stack slices will not be executed since they
are not currently linked into the chain.
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
I wonder,
Why does stackless redefine PyHeapTypeObject?
Is there any reason to? Can we fix that so that compatibility with stuff such as PyQT is maintained?
K
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
I had the unfortunate experience of mixing python and C++ code on the Windows environment on a large program with multiple libraries not written by me.
The C++ code uses the structured exception handling protocol, and stackless does no properly handle this. This could result in crashes in the following way:
Whenever a python tasklet is suspended the top of the exception chain is saved by stackless. This very well could be pointing into code above the python stack into the main program. When the python tasklet is called again, it's stack is put back *in the same place*, but the environment above the stack *might be different*. This would cause the exception chain to screw up in the part where the exception chain points above the stack.
This would cause a crash on an exception... for example a function uses OutputDebugStr (which routes by using an exception).... the exception handler itself could crash.
I have corrected this issue in my local copy of Stackless.. it involves changes to stacklesseval.c and involves patching the exception chain properly when tasklet switching, in cases when windows structured execption handling is defined. I have not contributed to stackless open source before, but I think anyone else getting peculiar crashes with exceptions on Windows might appreciate this fix.
I would like someone to explain the procedure to contribute to me.
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
Hi there.
Working on stuff to spawn off work for actual worker threads, I realized that there was no good way to to synchronize between two tasklets on two threads.
That is to say:
When sending data between two tasklet on the same thread, usually it is sufficient to use tasklet.set_atomic() to disable tasklet interrupts (that rarely happen anyway, only when using stackless.run() with non-zero values) to ensure atomicity.
For example, this code from stacklesslib.locks.Event:
def wait(self, timeout=None):
with atomic():
if self._is_set:
return True
lock_channel_wait(self.chan, timeout)
return self._is_set
def set(self):
with atomic():
self._is_set = True
for i in range(-self.chan.balance):
self.chan.send(None)
the atomic() context manager is used here to ensure consistency of state.
However, I realized that when using the Event to set or wait for events between threads, that is, when one tasklet was waiting and another, on a different thread, was setting the event, this approach doesn‘t work. A thread switch can happen anywhere, for example, in wait after the initial _is_set test, but before the wait, causing a lost wakeup bug.
The solution is to make „atomic“ also suspend automatic thread switching while in progress. I‘ve implemented this for our patched CCP version of stackless and wanted to mention this here before rolling it into the distribution. One thing that only slightly worries me is that this approach assumes a GIL-like implementation. But stackless being so specialized, we are unlikely to see a non-GIL version any time soon J
K
_______________________________________________ Stackless mailing list Stackless@... http://www.stackless.com/mailman/listinfo/stackless
I'm interested in installing Stackless on a Ubuntu VM I have (8.04). In this email ... http://www.stackless.com/pipermail/stackless/2008-April/003424.html ... issues are discussed with a stackless installation making future use of the the pre-existing CPython installation problematic (specifically the common use of the PYTHONPATH environment variable). Given that email is four years old I wondered if things had changed and/or someone had a suggestion for completely isolating stackless ? regards Richard.
RSS Feed26 | |
|---|---|
28 | |
25 | |
10 | |
27 | |
15 | |
12 | |
12 | |
45 | |
34 | |
25 | |
13 | |
5 | |
7 | |
28 | |
54 | |
34 | |
20 | |
22 | |
10 | |
43 | |
38 | |
25 | |
42 | |
32 | |
40 | |
52 | |
33 | |
67 | |
65 | |
93 | |
65 | |
6 | |
41 | |
52 | |
38 | |
27 | |
47 | |
101 | |
53 | |
87 | |
25 | |
53 | |
84 | |
37 | |
17 | |
29 | |
37 | |
53 | |
86 | |
55 | |
62 | |
55 | |
42 | |
57 | |
62 | |
103 | |
98 | |
67 | |
56 | |
39 | |
73 | |
123 | |
102 | |
52 | |
20 | |
75 | |
82 | |
43 | |
79 | |
68 | |
40 | |
81 | |
42 | |
72 | |
6 | |
5 | |
15 | |
11 | |
14 | |
30 | |
7 | |
9 | |
6 | |
3 | |
15 | |
5 | |
3 | |
3 | |
27 | |
3 | |
7 | |
4 | |
9 | |
17 | |
15 | |
78 | |
99 | |
116 | |
24 | |
25 | |
40 | |
50 | |
78 | |
51 | |
31 | |
4 | |
23 | |
27 | |
45 | |
12 | |
4 | |
7 | |
65 | |
60 | |
51 | |
13 | |
32 | |
6 | |
32 | |
41 | |
33 | |
2 | |
1 | |
1 | |
13 | |
3 | |
3 | |
6 | |
13 | |
44 | |
29 | |
29 | |
4 | |
62 | |
72 |
