<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Billy,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Sep 2017, at 17:11, Billy Poon <<a href="mailto:BKPoon@lbl.gov" class="">BKPoon@lbl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I just chatted with Tristan Croll from Cambridge at the Phenix developer workshop. Would the Global Interpreter Lock be an issue?<div class=""><br class=""></div><div class=""><a href="https://docs.python.org/2.7/c-api/init.html#thread-state-and-the-global-interpreter-lock" class="">https://docs.python.org/2.7/c-api/init.html#thread-state-and-the-global-interpreter-lock</a><div class=""><div class=""><br class=""></div></div></div><div class="">It sounds like we should be releasing the lock before doing any threading and then reacquiring the lock afterwards.</div></div></div></blockquote></div><br class=""><div class="">So that means you plan your threaded code to call back into Python, then? This would be quite unusual in the context of the cctbx but I haven’t followed development closely for a long while, so I might have missed something.</div><div class=""><br class=""></div><div class="">Best wishes,</div><div class=""><br class=""></div><div class="">Luc</div><div class=""><br class=""></div></div></body></html>