gmane.comp.python.stackless

stackless bug fix

Kristján Valur Jónsson — 2012-05-21T14:54:42

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< at >public.gmane.org
http://www.stackless.com/mailman/listinfo/stackless

Tasklet cleanup?

Sylvain Prat — 2012-05-19T22:29:19

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 tryi

Is the Stackless website down?

Fernando Miranda — 2012-05-10T20:11:10

I cannot reach the website from Buenos Aires. It's just me?

Using Stackless Python to overcome GIL issues interoperating with a C++ runtime

Adam Preble — 2012-05-06T10:25:37

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

Tasklet clean up

Fernando Miranda — 2012-04-29T06:09:02

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.

channels and StopIteration

Kristján Valur Jónsson — 2012-04-11T13:49:50

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< at >public.gmane.org
http://www.stackless.com/mailman/listinfo/stackless

Patch to exception handler.

Gil Colgate — 2012-04-09T18:43:34

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

http://www.stackless.com/pipermail/stackless/2007-April/000142.html

Kristján Valur Jónsson — 2012-04-04T09:28:55

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< at >public.gmane.org
http://www.stackless.com/mailman/listinfo/stackless

Exception handling crashes, how to contribute

Gil Colgate — 2012-04-03T16:28:19

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

tasklet.set_atomic

Kristján Valur Jónsson — 2012-04-02T10:00:34

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

Stackless co-existence with CPython - does this emailstill hold ?

Richard Shea — 2012-04-02T10:00:03

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.

multiprocess channels

2012-03-27T16:09:06

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

how nonblocking send and receive tasklet's messageusing c api?

Simon Liu — 2012-03-24T03:44:03

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.

Is there a Pycon 2012 Trip Report

Andrew Francis — 2012-03-13T16:45:04

Hi folks:

I am curious. Is anyone going to write a Pycon trip report?

Cheers,
Andrew_______________________________________________
Stackless mailing list
Stackless-KA+417sA3NeakBO8gow8eQ< at >public.gmane.org
http://www.stackless.com/mailman/listinfo/stackless

Stackless runtime smacking into GIL while a callback isrunning

Adam Preble — 2012-03-11T19:28:32

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 wa

Stackless socket module for pyuv

Richard Tew — 2012-03-03T01:14:25

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.

pricelezdyme10

Allen Fowler — 2012-03-01T18:14:15

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

pricelezdyme10

Allen Fowler — 2012-03-01T18:14:15

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

tasklet time out

piyush singhai — 2012-02-29T07:00:26

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< at >public.gmane.org
http://www.stackless.com/mailman/listinfo/stackless

Stackless Python 3.2.1 & 3.2.2 released

Richard Tew — 2012-02-20T23:02:02

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.

Stackless Python 3.2.1 & 3.2.2 code pushed

Richard Tew — 2012-02-19T06:49:14

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.