|Subject:||Re: Concurrency, again|
|Date:||Wed, 19 Oct 2016 03:02:20 -0400|
From my notes I thought that came out of the 2013 discussion, but I can’t find anything in the archives at the moment. Looks like I put it in the wrong sections of my notes.
Last November I put in a patch (commit b87000208) changing a few the select calls because of locking issues; the global lock still needed to be held while xg_select called routines like unblock_input, so I pushed the thread_select wrapper (which releases and re-acquires the lock) calls to a lower level.
In ns_select it wasn’t clear to me where to put the calls. It’s also clearly using static storage for fd arrays, which is a no-no if multiple threads will be able to call into that routine concurrently. So I added a “FIXME” statement to nsterm.m to prevent compilation of a version known to be wrong.
Depending how the NS version needs to change, possibly the “thread_select(pselect,…)” calls should be replaced with a wrapper specifically for pselect-using platforms, and the NS code manage the global lock separately. Or perhaps we’ll wind up with an NS-specific pselect-like routine that we pass to thread_select on the Mac, keeping the global lock management in one place.
|[Prev in Thread]||Current Thread||[Next in Thread]|