BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.com//scipy-2026//talk//HBZ9RC
BEGIN:VTIMEZONE
TZID:CST
BEGIN:STANDARD
DTSTART:20001029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T080000Z
TZNAME:CST
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T030000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:CST
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000402T030000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T090000Z
TZNAME:CDT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T030000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:CDT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-scipy-2026-HBZ9RC@pretalx.com
DTSTART;TZID=CST:20260715T112500
DTEND;TZID=CST:20260715T115500
DESCRIPTION:If you messed around with Python's command line options or read
  the official documentation\, you might wonder what the -Xgil option or th
 e PYTHON_GIL environment variable did to your scripts\, and whether settin
 g either affects performance. The hubbub on popular wheels such as pyo3\, 
 python-zstandard\, numpy\, uv\, cffi\, and cython supporting the free-thre
 aded interpreter is no passing fad either. For Pythonistas that don't read
  PEPs in their spare time or contribute to the cpython project itself\, an
  adventure that delves into a less known\, yet jaw-dropping aspect of Pyth
 on awaits!\n\nPython's Global Interpreter Lock\, which determines which si
 ngle thread can execute native Python code and call C API functions\, simp
 lifies writing multithreaded code. However\, sticking with this execution 
 model leaves out extra performance afforded by modern multicore CPUs with 
 hyperthreading\, as automatic locking and unlocking of the GIL does not sc
 ale well with thread counts\, especially in performance-sensitive workload
 s.\n\nThe newfangled free-threaded interpreter promises salvation when run
 ning either pure Python code or with compiled extensions. General multithr
 eading rules apply (prefer thread-local variables\, using locks to prevent
  simultaneous access of shared data)\, but when dealing with projects cont
 aining compiled extensions that directly or indirectly interface with Pyth
 on's C API\, more porting rules also apply.\n\nKey porting tips\, includin
 g projects using the Limited API\, include: port native code away from C A
 PI functions that avoid borrowed references because they aren't thread-saf
 e\; modify unit tests to catch concurrency bugs arising from assuming the 
 presence of the GIL\; and extend CI coverage of Python interpreters both f
 or testing and to build free-threaded compatible wheels.\n\nOutline:\n* In
 troduction (2-3 min.)\n* What is the -Xgil option?\n* What is the GIL?\n* 
 What is the free-threaded interpreter? (6-8 min.)\n* Global Interpreter Lo
 ck: downsides of automatic serialization of parallel workloads\n* How to t
 ry out the free-threaded interpreter\n* Increased parallelism with the no-
 GIL interpreter with multi-core CPUs\n* Porting tips (15-18 min)\n* Adding
  a trove classifier in pyproject.toml\n* Marking your extension module as 
 supporting no-GIL\n* Limited API (and PEP 803)\n* Bumping key dependencies
 \, including FFI wheels\n* Using locks\, mutexes\, and atomics in native c
 ode to prevent concurrency bugs\n* Including pytest-run-parallel to catch 
 threading bugs\n* Closing Remarks (2 min.)\n* Q&A (2 min.)
DTSTAMP:20260715T023320Z
LOCATION:Memorial Hall
SUMMARY:Tying Up Loose Threads: Making your Project No-GIL Ready - Charlie 
 Lin
URL:https://pretalx.com/scipy-2026/talk/HBZ9RC/
END:VEVENT
END:VCALENDAR