> -----Original Message----- data and decides, that the tasklet shall be run on a worker thread. > > Problem: as far as I know, a tasklet bound to a thread (via cstate) and this > association can't be changed. The best we can do is to create a new tasklet > on the worker thread, that belongs to the worker thread.
This is right. Although actually, for picklable tasklets (tasklets without a c state) this restriction Is artificial. > reducedTask = task.__reduce__() > # raise RuntimeError, if task is alive but not paused > task.bind(None) > > if True: # python will crash if set to False > frameList = reducedTask[2][3] > for i in range(len(frameList)): > frame = frameList[i] > if isinstance(frame, stackless.cframe): > reducedFrame = frame.__reduce__() > newFrame = reducedFrame[0](*reducedFrame[1]) > newFrame.__setstate__(reducedFrame[2]) > frameList[i] = newFrame > # rebind the task > task = reducedTask[0](*reducedTask[1]) > task.__setstate__(reducedTask[2]) > return task > Looks like you are doing recursive pickling of the tasklet by hand, but only for the cframes, not regular frames. Why can't you just use return pickle.loads(pickle.dumps(task))? We can discuss the possibility of transferring picklable tasklets between threads. As long as a tasklet is soft-switchable it really doesn't care which thread it runs on. A "bind_to_thread() method could be provided... But we can also think more of thread agnostic tasklets. We could even have a global run-queue of thread-agnostic tasklets that threads could access.... I'd like to understand your use case, however. It looks as though you are unpickling tasklets on one thread, then a pool of worker threads are accessing these tasklets and attempting to run them, is that right? For that purpose, a worker thread needs to "claim" the tasklet as its own. K _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
