From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Async DNS lookups Date: Thu, 04 Nov 2010 10:15:45 -0400 Message-ID: References: <35456.130.55.118.19.1288819785.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1288880166 10996 80.91.229.12 (4 Nov 2010 14:16:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Nov 2010 14:16:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 04 15:16:02 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PE0be-0005ka-Jw for ged-emacs-devel@m.gmane.org; Thu, 04 Nov 2010 15:15:58 +0100 Original-Received: from localhost ([127.0.0.1]:41952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PE0bd-0006n3-J9 for ged-emacs-devel@m.gmane.org; Thu, 04 Nov 2010 10:15:57 -0400 Original-Received: from [140.186.70.92] (port=54153 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PE0bU-0006lJ-1Q for emacs-devel@gnu.org; Thu, 04 Nov 2010 10:15:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PE0bS-0006KU-K5 for emacs-devel@gnu.org; Thu, 04 Nov 2010 10:15:47 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:26572 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PE0bS-0006KI-GH for emacs-devel@gnu.org; Thu, 04 Nov 2010 10:15:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogKAIdc0kzO+LrP/2dsb2JhbACgcIEFcr0ohUYEki0 X-IronPort-AV: E=Sophos;i="4.58,296,1286164800"; d="scan'208";a="81579926" Original-Received: from 206-248-186-207.dsl.teksavvy.com (HELO pastel.home) ([206.248.186.207]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 04 Nov 2010 10:15:45 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 22C53A8626; Thu, 4 Nov 2010 10:15:45 -0400 (EDT) In-Reply-To: (Andreas Schwab's message of "Thu, 04 Nov 2010 09:27:39 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132356 Archived-At: >>>> I think the implication is that you would have to add one (and use it >>>> every time any code whatsoever accessed that variable). >>> It's already being used several places without any locking. >> Indeed, because it's only accessed by a single thread right now (it's >> not even accessed from a signal handler). So you'd have to add locking >> if it becomes shared between threads. > Since it is using Lisp values it cannot be used by anything but the main > thread anyway. It's true that the other thread can't do things like call Fcons (before the allocation code is not synchronized either), but the other thread can still perform an assignment to a Lisp_Object variable, as long as that variable is properly synchronized. So you just have to ensure that the allocation of the pending_funcalls element is done before forking the new thread. I.e. when the name resolution is over, the other thread will want to do something like: lock(pending_funcalls); setcar(result, pending_funcalls); pending_funcalls = result; unlock(pending_funcalls); Of course, that leaves open the problem of how to translate the non-Lisp result into Lisp_Objects. I.e. you'll probably want to use some new variable, very similar to pending_funcalls, but for "pending_c_funcalls" so that the pending calls can first do some C preprocessing to turn the C result data into Lisp data and then call the Elisp callback. Stefan