unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: grischka <grishka@gmx.de>
Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
	emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
Subject: Re: System calls without error checks in w32
Date: Tue, 8 Jun 2010 02:32:28 +0200	[thread overview]
Message-ID: <AANLkTinrNz0Odb_1cm-NXduOAGj-slVuWoOdh_ANBHF1@mail.gmail.com> (raw)
In-Reply-To: <4C0D4078.1030208@gmx.de>

On Mon, Jun 7, 2010 at 8:54 PM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>
>> On Mon, Jun 7, 2010 at 7:21 PM, grischka <grishka@gmx.de> wrote:
>>>
>>> Lennart Borgman wrote:
>>>>
>>>> I guess the idea of having two event loops/thread is not in itself
>>>> bad. If the gui thread is never blocked it can be used to convey
>>>> status information at least to the user. (You can put these in
>>>> temporary windows inside the frame for example.)
>>
>>> Since this is Emacs you'd probably want to format your status info
>>> in Lisp.  Bye nice idea and welcome to thread hell.
>>
>> I see no reason to format it in Lisp. Or rather my idea is that the
>> status information is formated by the lisp thread in advance and sent
>> to the gui thread in a non-lisp format. Then the gui thread can offer
>> that information without contactinog the lisp thread.
>
> But then what is the benefit from that additional effort of preparing
> and sending a "non-lisp" representation forth and back, except to satisfy
> the requirements of having two threads?  Have only one thread and you
> can format and display the info in one go.  Simple, reliable, conclusive.


I suppose the rational for having two threads is that basic gui
operations should not be stalled by lisp computations. I do not know
how it is actually implemented now in Emacs but with two threads you
can post messages between them to coordinate them without interrupting
the gui handling badly. Here is an example:

- the user resize the frame during a lisp computation. The resizing
happens then entirely in the gui thread.

- When resizing is finished the gui thread can send a message telling
that to the lisp queue.

- The lisp queue can then handle this when it has time to do that and
ask the system for the new frame size.

- The gui thread can also send resizing messages during resizing which
the lisp thread can safely ignore if it is occupied since the
information is available later.
The gui thread can send a message to the lisp thread when resizing is
finished and tell that resizing has been done. The



  reply	other threads:[~2010-06-08  0:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31  9:18 System calls without error checks in w32 grischka
2010-06-05 17:15 ` Jason Rumney
2010-06-07 10:37   ` grischka
2010-06-07 14:54     ` Stephen J. Turnbull
2010-06-07 15:23       ` Lennart Borgman
2010-06-07 17:21         ` grischka
2010-06-07 17:30           ` Lennart Borgman
2010-06-07 18:54             ` grischka
2010-06-08  0:32               ` Lennart Borgman [this message]
2010-06-08  0:34                 ` Lennart Borgman
2010-06-07 19:56         ` Stefan Monnier
2010-06-07 23:35           ` Lennart Borgman
  -- strict thread matches above, loose matches on Subject: below --
2010-05-29  2:38 Lennart Borgman
2010-05-29 17:43 ` Eli Zaretskii
2010-05-29 18:42   ` Lennart Borgman
2010-05-29 19:35     ` Eli Zaretskii
2010-05-29 20:02       ` Lennart Borgman
2010-05-29 21:25         ` Eli Zaretskii
2010-05-29 21:30           ` Lennart Borgman
2010-05-30  3:02             ` Eli Zaretskii
2010-05-30  3:26               ` Lennart Borgman
2010-05-30 17:36                 ` Eli Zaretskii
2010-05-30 18:02                   ` Lennart Borgman
2010-05-30 19:24                     ` Juanma Barranquero
2010-05-30 22:37                       ` Lennart Borgman
2010-05-30 23:03                         ` Juanma Barranquero
2010-05-30 23:28                           ` Lennart Borgman
2010-05-31  0:10                             ` Juanma Barranquero
2010-05-31  0:58                               ` Lennart Borgman
2010-05-31  2:02                                 ` Juanma Barranquero
2010-05-31  2:36                                   ` Lennart Borgman
2010-05-31  3:06                                     ` Juanma Barranquero
2010-05-31  3:05                         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinrNz0Odb_1cm-NXduOAGj-slVuWoOdh_ANBHF1@mail.gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=grishka@gmx.de \
    --cc=jasonr@gnu.org \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).