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

[Mike Fletcher]

Would _love_ to be able to send the code, but letting someone outside the
company see this particular code (research results involving long-range
strategy) would involve enough lawyers and managers that I'd have time to
rebuild the system 10 times before I got permission.  Ah to work in Open
Source.

Okay, lets see if I understand this:

System Thread <os thread>
	uthreadLock = 0 or 1, determines whether switches can occur, is a
global variable effectively.  Assumed to be protected because when it's set,
no other uthread can be active.  Guarantee fails when a thread is blocked,
as there's no storage/retrieval of the lock state performed by uthread9's
scheduler

uthread9
	says uthreadLock = 1 # lock
		runs function
			# function suspends (blocks)
			# scheduler runs, clears lock

### TIME PASSES, THINGS CHANGE
			# thread unblocks
			# uthreadLock = unlocked, since running scheduler
			# chaos strikes if something really needed that lock
		finally clause runs (again?), sets to "previous value" which
represents what the callers of atomic had set up in their environment...
which is desirable.

Approaches (shout if one doesn't sound crazy):
	Possibly alter scheduler to store (blocked, lockState) in blocked
dictionary with corresponding structure in pendingThreads and some logic in
the main loop to wonk it?
	Maybe better, if currently atomic: wrap the continuation in a call
to atomic (i.e. use makeTask( atomic, (continuation,), {}) ) and store that
instead of the raw continuation?  Relies on finally clause being called,
otherwise need to explicitly clear the lock.  Do continuations ever return?
I don't think so... so finally never gets called :( .  Okay, maybe a simple
function that sets the lock to the correct value then calls the
continuation?  This seems doable, and if I understand everything correctly,
would fix the lock problem (not necessarily the crashing, but the locks
would be consistent).  Sounds like it's time for uthread10...

Re: reducing caught exceptions:
	My code is pretty general, it has hundreds of exceptions that can be
raised (think of it as a general RPC system with arbitrary code modules
everywhere), so trying to catch just a sub-set doesn't work particularly
well.  I'll try turning off exception handling if I get a chance.

Ah well, back to writing presentations, enjoy yourself, and thank-you for
all the help. I'll try to get time to test the "fix" above tonight (or maybe
tomorrow),
Mike


-----Original Message-----
From: Christian Tismer [mailto:tismer at appliedbiometrics.com]
Sent: Monday, September 18, 2000 4:19 AM
To: Mike Fletcher
Cc: Python List (E-mail)
Subject: Re: Weird pointer errors... Stackless problem?
PyString_InternInPlace Fatal error
...
The lock is not in the continuation.
The lock is in the thread_state of your system thread.
...
No, not removing, but make them specific to the exceptions
which you expect, and let others make it through.

NOTE!: The lock flag is also cleared automatically if the
scheduler is run. So, regardless of the lock state:
Whenever a task is run by the scheduler, then there is no lock.
...
Why don't you just give me a copy of your code?
...