From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Thu, 03 Nov 2016 12:43:18 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> <83bmy0pl8p.fsf@gnu.org> <831sywp7ew.fsf@gnu.org> <83y413nsjm.fsf@gnu.org> <83funbnngl.fsf@gnu.org> <83d1ifnmto.fsf@gnu.org> <20161101152027.5e94b6cc@jabberwock.cb.piermont.com> <83ziljm0ei.fsf@gnu.org> <7875855e-b632-491c-c616-4f3662a525af@dancol.org> <83vaw7lyoc.fsf@gnu.org> <83mvhhnaul.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1478144644 7646 195.159.176.226 (3 Nov 2016 03:44:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 3 Nov 2016 03:44:04 +0000 (UTC) User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 03 04:43:57 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c28wB-0006YC-24 for ged-emacs-devel@m.gmane.org; Thu, 03 Nov 2016 04:43:35 +0100 Original-Received: from localhost ([::1]:58777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c28wD-00008A-Ho for ged-emacs-devel@m.gmane.org; Wed, 02 Nov 2016 23:43:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c28w8-00007u-30 for emacs-devel@gnu.org; Wed, 02 Nov 2016 23:43:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c28w7-0004ok-2L for emacs-devel@gnu.org; Wed, 02 Nov 2016 23:43:32 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:58379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c28w2-0004lc-4k; Wed, 02 Nov 2016 23:43:26 -0400 Original-Received: from fermat1.math.s.chiba-u.ac.jp (fermat [192.168.32.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E41F4F08EE; Thu, 3 Nov 2016 12:43:18 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: <83mvhhnaul.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209133 Archived-At: >>>>> On Wed, 02 Nov 2016 17:46:26 +0200, Eli Zaretskii said: >> 1489 dispatch_group_async (group, queue, ^{ >> 1490 int nkeys; >> 1491 uintptr_t key; >> 1492 nkeys = nkeys_or_perm; >> 1493 for (key = row * (256 / NGLYPHS_IN_VALUE); ; key++) >> 1494 if (CFDictionaryContainsKey (dictionary, >> 1495 (const void *) key)) >> 1496 { >> 1497 CFDictionaryRemoveValue (dictionary, >> 1498 (const void *) key); >> 1499 if (--nkeys == 0) >> 1500 break; >> 1501 } >> 1502 }); >> >> I can disable this for NS if it does not fit with the current policy >> of GNU Emacs mainline source code. > I know next to nothing about NS. These are system APIs, right? If > so, calling them could be okay, and I defer to NS and OS X people here > to make that call. They internally use malloc/free. What if the code like above were using malloc/free instead of CF functions? BTW, I just remember the current implementation of xfree should not be used from a non-main thread if XMALLOC_BLOCK_INPUT_CHECK is defined. The Mac port contains a code that calls "free" off the main thread for some data that were allocated in the main thread. void mac_free_gc (GC gc) { CGColorRelease (gc->cg_fore_color); CGColorRelease (gc->cg_back_color); if (gc->clip_rects_data) CFRelease (gc->clip_rects_data); #if defined (XMALLOC_BLOCK_INPUT_CHECK) && DRAWING_USE_GCD /* Don't use xfree here, because this might be called in a non-main thread. */ free (gc); #else xfree (gc); #endif } > One things bothers me, though: can't this arrangement, where data is > allocated in one thread and deallocated in another, cause races? Or > do these threads have means to synchronize between them? For CFDictionary itself, its fundamental operations are thread-safe, as well as malloc/free. For the font data structure that use CFDictionary, the main thread waits for the other thread after doing some independent tasks that do not use CFDictionary. 1543 if (group) 1544 { 1545 dispatch_group_wait (group, DISPATCH_TIME_FOREVER); 1546 dispatch_release (group); 1547 } 1548 } YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp