From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lisp object that refers to a C struct Date: Wed, 17 Oct 2012 17:50:09 +0200 Message-ID: <83mwzl2j4e.fsf@gnu.org> References: <83ehkz4edw.fsf@gnu.org> <83bog33wdr.fsf@gnu.org> <837gqq49j7.fsf@gnu.org> <83r4ox3frd.fsf@gnu.org> <87r4ox62kr.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350489057 7195 80.91.229.3 (17 Oct 2012 15:50:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 15:50:57 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 17 17:51:04 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TOVtd-0007VE-TY for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2012 17:51:02 +0200 Original-Received: from localhost ([::1]:43949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOVtW-00083E-VE for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2012 11:50:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOVtP-00082t-5Z for emacs-devel@gnu.org; Wed, 17 Oct 2012 11:50:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOVtK-00082q-3X for emacs-devel@gnu.org; Wed, 17 Oct 2012 11:50:47 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:52678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOVtJ-00082k-RA for emacs-devel@gnu.org; Wed, 17 Oct 2012 11:50:42 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MC100A00NXJYF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 17 Oct 2012 17:49:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MC1009LRNZ7TZI0@a-mtaout20.012.net.il>; Wed, 17 Oct 2012 17:49:55 +0200 (IST) In-reply-to: <87r4ox62kr.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154382 Archived-At: > From: "Stephen J. Turnbull" > Cc: Stefan Monnier , > emacs-devel@gnu.org > Date: Wed, 17 Oct 2012 15:21:40 +0900 > > Eli Zaretskii writes: > > > > What happens if someone passes you this same integer some time after > > > you've freed the C struct? > > More interesting, what happens if somebody chooses "I feel lucky" and > passes you a random integer that happens to be a "live" watch? I don't follow: what do you mean "somebody passes me a random integer"? There are only 2 APIs that expose this integer to Lisp: one that starts watching for file changes, and another that cancels an existing watch. The former returns the integer we are talking about, the latter accepts that integer and uses it to access the underlying C struct, shut down the thread that was doing the watch, and delete the struct and all the other resources the watch was using. So if they pass me the integer that happens to reference a live watch, they can only do that through the "remove" API, in which case the watch will stop. Or did you mean something else? > ISTM it fails safe (ie, doesn't crash). It's fail-safe, yes (well, barring bugs ;-). > But it's not good. Why not? If a luser asked to shut down a watch, and just "happened" to specify a live one, she gets what she asked for. It's not like Emacs _needs_ those watches for some of its internal workings. > So really you want this to be entirely internal somehow. The only > way to do that is to have an opaque type that you can only get a > pointer to from the watch constructor. I don't think we have opaque data types in Emacs.