From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] system-type cygwin with window-system w32 Date: Mon, 18 Jul 2011 12:11:25 -0700 Message-ID: <4E24855D.5030607@gmail.com> References: 4E240C17.4020102@gmail.com <4E246E75.6040807@gmx.de> <4E24726D.1080609@gmail.com> <4E2476BA.40201@gmail.com> <4E2480E6.5040306@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig868284C88F2F63BD3EC211C3" X-Trace: dough.gmane.org 1311017040 16037 80.91.229.12 (18 Jul 2011 19:24:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 19:24:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 21:23:56 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QitQ2-00038f-RP for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 21:23:55 +0200 Original-Received: from localhost ([::1]:56564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QitQ1-00060Y-9s for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 15:23:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QitPf-0005zO-6s for emacs-devel@gnu.org; Mon, 18 Jul 2011 15:23:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QitPZ-0007SB-2Q for emacs-devel@gnu.org; Mon, 18 Jul 2011 15:23:29 -0400 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:43075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QitE1-0006F1-US for emacs-devel@gnu.org; Mon, 18 Jul 2011 15:11:30 -0400 Original-Received: by pvc12 with SMTP id 12so3927797pvc.0 for ; Mon, 18 Jul 2011 12:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type; bh=4M+CQGNcHEzNBxXIRobKle2C9jSSdzr/EODdIY+j8OI=; b=i7ybimHVBGy2CTn37IkUtzrlM9/8XpxdJEXwPubQZOnHf7kMpxyAbQbD3gExYMBtin MohAsVr6UtmdaErNtPAbcegSHglk29XIv9KWEjcJ/F7rPiKxNC11qTPe8Icx1OfKSXiB IMd/I6GV8M6wJhEqKcK166pK8rLgdYZlA3ctQ= Original-Received: by 10.68.17.138 with SMTP id o10mr3662394pbd.114.1311016288497; Mon, 18 Jul 2011 12:11:28 -0700 (PDT) Original-Received: from [0.0.0.0] (c-24-18-179-193.hsd1.wa.comcast.net [24.18.179.193]) by mx.google.com with ESMTPS id p7sm2600351pbn.49.2011.07.18.12.11.26 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 12:11:27 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <4E2480E6.5040306@gmx.de> X-Enigmail-Version: 1.2 OpenPGP: id=5035D15B X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.83.169 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:142135 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig868284C88F2F63BD3EC211C3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/18/2011 11:38 AM, grischka wrote: > Daniel Colascione wrote: >> If it works, /dev/windows would allow us to get rid of not only the >> self-pipe >> and the clipboard thread, but the UI thread as well, though it'd be >> easier to >> keep the last of these for compatibility for the NT build. Thanks. > > Actually the NT build works quite well with one single thread. > Already tested here. Do you have a patch handy? >> By the way: why do we use a separate UI thread in the NT case at all? >> AIUI, we >> can do everything we need asynchronously via overlapped IO, so we >> should never >> have to block and not pump messages. > > The 'sys_select' wrapper DOES pump messages, just for the wrong > thread. So it needs the thread because it has the thread. :) Of course. I suspect the initial motivation behind the separate thread is a long, somnolent story involving QUIT. > Well, there are two other things needed: > * peek for messages in the QUIT macro (say via ELSE_PENDING_SIGNALS) > which is for C-g to interrupt lisp. I don't think this approach alone would be sufficient. I may be wrong, but I think the Windows window manager will consider a program to be "unresponsive" if it stops actually pumping messages; I don't think peeking is sufficient. Also, [1] says that we shouldn't delay pumping messages even if we're able to guarantee we'll get around to them later. (Running lisp code is indistinguishable from sleep in this case.) Using PeekMessage in lisp code instead of actually pumping messages would be like telling your credit card company, "Yeah, I got the bill, and I'll get around to responding sometime in the next two years". I don't think it'd go over well. Actually, on that note, I should add a timeout to my WM_RENDERFORMAT code: we shouldn't block other applications forever merely because Emacs is spinning in Lisp. > * break command_loop_1() such that it can be used to handle just one > event which is to handle scrollbar messages because the widgets > run their own message loop deep in windows. Otherwise all the > scrolling would happen only after you release the mouse button. I doubt that the scrollbar is the only special case we'd need to consider= =2E On 7/18/2011 11:52 AM, grischka wrote: > Daniel Colascione wrote: >> This requirement is incompatible >> with using lisp code to render clipboard content: we might have >> received a >> window message at an inopportune time for calling back into Lisp, and >> we can't >> delay the response to WM_RENDERFORMAT by re-queuing or somesuch.=20 >> Today's NT >> clipboard code doesn't have to address the issue because it never >> calls into Lisp. >=20 > Well, you can do this if you have a function to pump elisp > events, say drain_lisp_queue(): >=20 > That would be basically command_loop_1() with > while (1) > replaced by > while (detect_input_pending()) >=20 > Then, in window_proc: > case WM_RENDERFORMAT: > queue_lisp_event(); //I guess it's "kbd_buffer_store_event_hold= " > drain_lisp_queue(); > break; >=20 > Or such. >=20 I don't understand how this approach helps. The problem, AIUI, isn't that we have Lisp events, but that we read input and wait for processes in many places, and it's hard to be confident that each place we pump messages is a safe place to process lisp code. I don't understand how draining the lisp event queue would help. [1] http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/529525.aspx --------------enig868284C88F2F63BD3EC211C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4khV0ACgkQ17c2LVA10VszpwCeOzGdDxw6M49PkIUUeuGqfb57 PXUAoJuLP2esjXYetMGTvoYLIiiCXphj =ISMX -----END PGP SIGNATURE----- --------------enig868284C88F2F63BD3EC211C3--