[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency, again

From: Ken Raeburn
Subject: Re: Concurrency, again
Date: Wed, 19 Oct 2016 03:02:20 -0400

On Oct 18, 2016, at 06:46, Alan Third <address@hidden> wrote:

On 18 October 2016 at 08:58, Ken Raeburn <address@hidden> wrote:
 * ns_select needs fixing

Do you have any more information about what's to be fixed here?

Alan Third

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]