http://blog.gmane.org/gmane.comp.python.stackless hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.stackless/5149 <pre>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 :) See http://blog.ccpgames.com/kristjan/ for details. K _______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Kristján Valur Jónsson 2012-05-21T14:54:42 http://comments.gmane.org/gmane.comp.python.stackless/5142 <pre>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 --&gt; tasklet --&gt; stackless machinery? --&gt; callable stack frame (bound method of wrapper) --&gt; 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 </pre> Sylvain Prat 2012-05-19T22:29:19 http://comments.gmane.org/gmane.comp.python.stackless/5128 <pre>I cannot reach the website from Buenos Aires. It's just me? </pre> Fernando Miranda 2012-05-10T20:11:10 http://comments.gmane.org/gmane.comp.python.stackless/5125 <pre>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: 1. Python interpreter calls something with a wrapper into C++. 2. C++ code calls back into a Python implementation of a C++ interface (GIL involved here). 3. Python implementation calls some other thing wrapped from C++ . . . note that step #1 hasn't actually completed yet. 4. C++ code calls back into Python. Here we deadlock trying to get the GIL. I'm looking at a situation here where I need to place all these pending GIL-related operations on some common stack, and have something comb over them. When that comber realizes it already took the GIL, and it's being told to do a new operation, it can at least do some negotiation with itself. I don't know how the GIL works entirely here since I haven't implemented this logic yet, but it's clear I have to do something. At the worst I assume I will have to save the interpreter stack from the prior call before moving on to the next call. It occurred to me there could be some nice ways to do this with coroutines. I'm already pondering some stuff Boost has for coroutines that might make this a lot less ugly, but I wondered if Stackless had something that could come to the rescue. I don't know what it could possibly be, but I thought I'd ask the list for advice. _______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Adam Preble 2012-05-06T10:25:37 http://comments.gmane.org/gmane.comp.python.stackless/5122 <pre>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. </pre> Fernando Miranda 2012-04-29T06:09:02 http://comments.gmane.org/gmane.comp.python.stackless/5105 <pre>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-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Kristján Valur Jónsson 2012-04-11T13:49:50 http://comments.gmane.org/gmane.comp.python.stackless/5103 <pre>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-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Gil Colgate 2012-04-09T18:43:34 http://comments.gmane.org/gmane.comp.python.stackless/5093 <pre>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-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Kristján Valur Jónsson 2012-04-04T09:28:55 http://comments.gmane.org/gmane.comp.python.stackless/5091 <pre>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-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Gil Colgate 2012-04-03T16:28:19 http://comments.gmane.org/gmane.comp.python.stackless/5088 <pre>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 :) K _______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Kristján Valur Jónsson 2012-04-02T10:00:34 http://comments.gmane.org/gmane.comp.python.stackless/5087 <pre>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. </pre> Richard Shea 2012-04-02T10:00:03 http://comments.gmane.org/gmane.comp.python.stackless/5079 <pre>Hey there, I have started playing with the multiprocessing package together with stackless. I came up with this POC implementation of the channels, working across processes. If any of you stackless gurus could take a quick look there: http://www.internike.com/mp_stackless.html and let me know if you see any serious flaw with the basic concept, before I get too excited about it, I'd be infinitely grateful ;-) Nike </pre> stackless.nst-HfgdotR9GYVl57MIdRCFDg< at >public.gmane.org 2012-03-27T16:09:06 http://comments.gmane.org/gmane.comp.python.stackless/5077 <pre>Hi all. I am using stackless c api(stackless_api.h), but I have some question: when I new a tasklet and run it, I lost control this new tasklet, example I want know this new tasklet whether dead or done. afterwards I try use channel, but in my main tasklet , everything must be nonblocking. so how nonblocking send and receive tasklet's message? like erlang's spawn_link. thanks. </pre> Simon Liu 2012-03-24T03:44:03 http://comments.gmane.org/gmane.comp.python.stackless/5072 <pre>Hi folks: I am curious. Is anyone going to write a Pycon trip report? Cheers, Andrew_______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Andrew Francis 2012-03-13T16:45:04 http://comments.gmane.org/gmane.comp.python.stackless/5065 <pre>I've been writing a C++ application with an embedded Python interpreter, for which I am using Stackless Python 2.6.5. I am using Boost to wrap my objects. I had the great fortune of running head-first into the GIL when I started calling back into Python objects that were implementing some C++ interfaces. These calls are coming in from a variety of threads in the C++ runtime, and the rest was history. Hence, I am no stranger to our friend "PyThreadState_Get: no current thread." I've learned how to acquire the GIL in my wrappers and there was peace in the land again. The problem this time is my call stack takes me right to the thread with the Stackless Python runtime in it, and not some imposter thread. I see the runtime itself trying to secure the thread state, and there I hit the error. In my Python code, I have this main thread running a horrific poll loop: # Busy loop while waiting for escape key while not self.stopLoop: stackless.schedule() Indeed this is a terrible way to do it, but it's a stop gap while I bring up a lot of other code. I am pretty sure if I improved on this with condition variables or monitors or whatever Stackless uses, that I would still have the problem--I may yet try this while waiting for some hints just to reduce the amount of bile I imagine that code is generating. The callback looks like this: def ReceiveInputEvent(self, inputType, eventData): print "Received input event" if inputType == CECControlTypes.QuitProgram: print "Setting stopLoop = True" self.stopLoop = True Right now when I hit escape, it will come back multiple times so long as I have held it down. That wasn't my goal, and I want to work on that, but it makes the problem much more chronic at the moment so I'm keeping it. It'll crash sometimes in the middle of this code, and sometimes after I have cleared it. The wrapper is doing this: PyGILState_STATE gstate = PyGILState_Ensure(); this-&gt;get_override("ReceiveInputEvent")(type, eventData); PyGILState_Release(gstate); This code is behaving for me; the Ensure call succeeds and I don't see issues with the release. Maybe I'm not checking for them? I have set breakpoints at the Ensure and Release and I see the error can also happen once I am clear of the Release. One thing is for certain--if I don't ever trigger that callback, everything is fine, or at least I don't get that error. I'm assuming that somehow Stackless didn't get the memo that I stole the interpreter for a moment for another thread. Is there some special rules I need to honor with it when I do this crazy stuff? Environment:] I'm using Boost 1.47 My OS is Vista 64-bit I'm using Visual Studio 2010 I'm building and running with debug symbols on, including Python. Stackless Python startup string: Python 2.6.5 Stackless 3.1b3 060516 (release26-maint, Feb 15 2012, 09:11:40) [MSC v.1600 32 bit (Intel)] on win32 I am using a 2.6 one since it mates up with Boost well. If we have good reason to move on to a newer one, I have to see what mates with Boost now and try to work with that. But let's say trying a new version of Stackless is nontrivial. I'm also assuming I just missed something and all would be well. _______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> Adam Preble 2012-03-11T19:28:32 http://comments.gmane.org/gmane.comp.python.stackless/5063 <pre>Hi, I've implemented the most commonly used part of a socket module based on pyuv, the Python bindings for libuv. You can find the most recent commit here: http://code.google.com/p/stacklessexamples/source/detail?r=191 This is unlikely to ever be as full-featured as the asyncore-based Stackless socket module, but given the breadth of functionality which libuv (and therefore pyuv) provides bindings for, it should if completed result in a wider support for asynchronous features. You can read pyuv's documentation here: http://readthedocs.org/docs/pyuv/en/release-0.5.0/ Cheers, Richard. </pre> Richard Tew 2012-03-03T01:14:25 http://comments.gmane.org/gmane.comp.python.stackless/5061 <pre> SingIe mom makes reaI money working at home onIine http://cafudermista.zxq.net/pjob4jou/httpjob4journal0129.php?afecampID=40 Thu, 1 Mar 2012 19:14:15 ______________ " [Illustration: KING RICHARD'S SEAL" (c) jaedon albertina </pre> Allen Fowler 2012-03-01T18:14:15 http://comments.gmane.org/gmane.comp.python.stackless/5060 <pre> SingIe mom makes reaI money working at home onIine http://cafudermista.zxq.net/pjob4jou/httpjob4journal0129.php?afecampID=40 Thu, 1 Mar 2012 19:14:15 ______________ " [Illustration: KING RICHARD'S SEAL" (c) jaedon albertina </pre> Allen Fowler 2012-03-01T18:14:15 http://comments.gmane.org/gmane.comp.python.stackless/5053 <pre>Hi, Some of my tasklets are blocked because of which whole system is blocked. There is a option of timeout in run method but it is not time it is depending on number of instruction, how Can i specify the time. suppose in my function if i write time.sleep(30) then every thing is block. can i avoid this situation. --Piyush _______________________________________________ Stackless mailing list Stackless-KA+417sA3NeakBO8gow8eQ&lt; at &gt;public.gmane.org http://www.stackless.com/mailman/listinfo/stackless</pre> piyush singhai 2012-02-29T07:00:26 http://comments.gmane.org/gmane.comp.python.stackless/5051 <pre>Hi, I've uploaded the releases of Stackless Python 3.2.2 and 3.2.1 to the Stackless web site. http://www.stackless.com/download/ In the case of 3.2.1, you'll have to look on the archived downloads page of course. If anyone wishes to build the missing MacOS releases, even if it just for 2.7.2 and 3.2.2, it would be much appreciated :-) Cheers, Richard. </pre> Richard Tew 2012-02-20T23:02:02 http://comments.gmane.org/gmane.comp.python.stackless/5050 <pre>Hi, I merged 3.2.1 and 3.2.2 some time ago, but there was a problem with leaked exception state which rendered them both unstable. I've debugged the problem, applied a fix, and pushed it to hg.python.org. If using the latest Python 3.2 releases upgraded with the Stackless shenanigans is of interest to you, you can retrieve the source and compile it yourself. You can put your local repository clone to the right revisions by doing one of the following: hg update -r v3.2.1-slp hg update -r v3.2.2-slp Unfortunately, I don't think there is an equivalently flexible command like "svn export" which can fetch an unversioned set of files from a remote repository. But maybe if you use one of the following links, you can use the "bz2", "zip" or "gz2" links on the left-hand side of the page to save any faffing around with Mercurial. 3.2.1: http://hg.python.org/stackless/rev/993f37332abf 3.2.2: http://hg.python.org/stackless/rev/4b587d500e94 I'll do the proper releases for each, hopefully tomorrow. They allocate each user 100 MB at the local library whose bandwidth I plan to use, so hopefully that be suitable :-) Cheers, Richard. </pre> Richard Tew 2012-02-19T06:49:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.stackless