From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Thu, 03 Nov 2016 19:40:30 +0200 Message-ID: <83bmxwmpgx.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1478194861 9690 195.159.176.226 (3 Nov 2016 17:41:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 3 Nov 2016 17:41:01 +0000 (UTC) Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 03 18:40:56 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 1c2Lzz-00075M-CE for ged-emacs-devel@m.gmane.org; Thu, 03 Nov 2016 18:40:23 +0100 Original-Received: from localhost ([::1]:34287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2M02-000715-79 for ged-emacs-devel@m.gmane.org; Thu, 03 Nov 2016 13:40:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2Lzt-00070X-Id for emacs-devel@gnu.org; Thu, 03 Nov 2016 13:40:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2Lzs-0004Yz-NL for emacs-devel@gnu.org; Thu, 03 Nov 2016 13:40:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2Lzn-0004WL-34; Thu, 03 Nov 2016 13:40:11 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1598 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c2Lzm-0001jz-49; Thu, 03 Nov 2016 13:40:10 -0400 In-reply-to: (message from YAMAMOTO Mitsuharu on Thu, 03 Nov 2016 12:43:18 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209136 Archived-At: > Date: Thu, 03 Nov 2016 12:43:18 +0900 > From: YAMAMOTO Mitsuharu > Cc: dancol@dancol.org, > raeburn@raeburn.org, > emacs-devel@gnu.org, > monnier@iro.umontreal.ca, > perry@piermont.com > > > 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. Yes, xmalloc/xfree should only be called from the main thread. The problem with calling malloc directly in Emacs is that you need to deal with failures, which is not trivial in Emacs, whereas xmalloc and friends has all that figured out already. > 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. Then I guess this is okay. Thanks.