Weird pointer errors... Stackless problem? PyString_InternIn Place Fatal error

[Mike Fletcher]

Background: Chris's fix stopped one particular manifestation, but the
general problem still exists...

I'm beginning to suspect something:
In atomic (the most commonly used function in uthread), we have a try
finally clause...

continuation_uthread_lock = continuation.uthread_lock
def atomic(func, *args, **kwargs):
	"""Perform a function call as a microthread-safe operation."""
	tmp = continuation_uthread_lock(1)
	try:
		return apply(func, args, kwargs)
	finally:
		continuation_uthread_lock(tmp)

Now, I have a (large) number of fairly new (i.e. added in the last few weeks
to fix other bugs that had emerged) cases in my code where I need atomic
action right up to the point where a thread blocks (and then after as well).
I've implemented this as:

atomic( thecall )

With the call blocking the thread as normal.  Now, this seems to work, the
system keeps running afterward (i.e. the atomic nature doesn't prevent other
threads from running once we block the thread), but I'm thinking the problem
may be that continuation_uthread_lock(tmp) is getting called twice on the
same "tmp" (once when blocked, once when un-blocked).  Thinking about it,
the lock likely isn't getting re-acquired after blocking when the
continuation is called, so I may have to alter uthreads to fix this stuff
anyway (not, of course, that I can see an elegant way to do that.)  I had
(almost certainly wrongly) assumed the lock was stored as part of the
continuation and was getting restored when the continuation was called.

So, would that scenario make sense as a source of the weird pointer errors?
What are the effects and semantics of continuation.uthread_lock,
particularly when a continuation jumps back into the middle of the function
holding such a lock.  Is there any way to test whether we currently have
continuation.uthread_lock locked?  If I just keep adding one lock (reading
the previous value) and popping two if the previous was non-0, could I read
the whole lock stack/set, then re-establish the stack when un-blocking a
thread?

Sleep helps clear your thoughts... or maybe I'm just dreaming again :)
Mike

-----Original Message-----
From: Christian Tismer [mailto:tismer at appliedbiometrics.com]
Sent: Friday, September 15, 2000 6:26 AM
To: Mike Fletcher
Cc: Python List (E-mail)
Subject: Re: Weird pointer errors... Stackless problem?
PyString_InternInPlace Fatal error
...
> Going to re-install everything now, but thoughts on how this could happen
> and be avoided in the future would be appreciated.

Please give it a try and keep me informed immediadelay
...