adam olsen kjbnfagmailcom mon mar 17 2008 102 pm guido van rossum wrote mon mar 17 2008 1256 pm adam olsen wrote guidos asked give quick status report go critical parts design implementation basically done ive implemented monitors contain objects without explicit threadsafe api let remove gil ive created synchronousasynchronous refcounting scheme reuses existing increfdecref api also minimizes contention used one thread net result although theres significant amount overhead demonstrate scalability one thread ive able test two cores though ive replaced __del__ api resurrected objects __finalize____finalizeattrs__ api doesnt attributes listed __finalizeattrs__ proxied core object finalizer thread given reference core main object deleted gc asynchronously notifies finalizer thread call core__finalize__ net result api similar __del__ need list attributes might use impossible gc run arbitrary code even enforce missing generator cleanup dont allow gc run generator long enough raise generatorexit alternative needed im currently working flushing design recently rewrote reenabled tracing gc next automatic deadlock detectionbreaking merging back cpython could build smaller patches design cant completely separated example __finalize__ called another thread monitors monitormethod applied dont specifically require monitor object therefor methods shareable monitor easiest way provide thanks would care give us hint typical multithreaded application would written using approach much preexisting code would break expect since forgot original post heres project site httpcodegooglecomppythonsafethread key advantage using monitors rather actors eventdriven scheme retain traditional style blocking function calls stdlib modules remain basically first conflict importing accessible another thread module object must shareable means everything references must also shareable enabled permodule basis using __future__ import shared_module shouldnt affect users module though unless modify globals class attributes expect apply stdlib module globals class dicts use shareddict still mutable requires keys values shareable stop modifying switch unlocked mode allowing uncontended reads writes point still work first one expensive behaviour discouraged bigger problem something like list module globals class dict list isnt threadsafe isnt shareable rejected youre using constant probably replace tuple frozenset modifying youll need wrap monitor like another big problem ive scrapped existing threadthreading modules getting semantics right would require retain gil least main monitorspace wouldnt get deadlock detection wouldnt support daemon threads etc grudgingly simple example spawn threads given httpcodegooglecomppythonsafethreadwikibranching branch children childrenaddfunc1 42 namebob childrenaddfunc2 args kwargs some_io_func basically use branch children create branching point childrenaddfunc args kwargs create child thread automatically joins threads try leave context one raises exception others including base thread cancelled encouraging stop stopped exceptions bundled together using pyexception_setcause possibly multipleerror propagated caller want collect results use childrenaddresultfunc instead follow data childrengetresults leave context must done explicitly avoid unintentionally keeping results alive longrunning server youre operating immutable data returning immutable result thats sufficient however build shared mutable object need turn monitors httpcodegooglecomppythonsafethreadwikimonitors class countermonitor implicit monitormethod __init__ __new__ def __init__self selfcount 0 monitormethod def tickself selfcount 1 monitormethod def valueself return selfcount basic idea acquires monitors lock monitormethod called dont see example checks arguments shareable well return value still write staticmethods classmethods self__dict__ inaccessible youre monitor also seen waitfunc leave monitor enterfunc used internally monitormethod options give explicit control recursivelocking situations much hasnt implemented still needs final design likewise havent added conditions yet adam olsen aka rhamphoryncus _______________________________________________ python3000 mailing list smsbmo9552pythonorg httpmailpythonorgmailmanlistinfopython3000 unsubscribe httpmailpythonorgmailmanoptionspython3000python300040tangomucom wed 06 aug 2008 061316 0600 python3000 pythonsafethread project status