From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Newsgroups: gmane.emacs.help Subject: Re: try-this-for ? Date: Fri, 19 Jan 2018 12:22:08 +0100 Message-ID: <20180119112208.GI7809@tuxteam.de> References: <86r2qn5qby.fsf@zoho.com> <86vafz4922.fsf@zoho.com> <86r2qm4wjz.fsf@zoho.com> <86shb22po8.fsf@zoho.com> <86k1we2kh0.fsf@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1516360852 14903 195.159.176.226 (19 Jan 2018 11:20:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 11:20:52 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: help-gnu-emacs@gnu.org To: Emanuel Berg Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 19 12:20:48 2018 Return-path: Envelope-to: geh-help-gnu-emacs@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 1ecUio-0002q1-9q for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Jan 2018 12:20:34 +0100 Original-Received: from localhost ([::1]:43244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecUko-0007Yj-Fc for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Jan 2018 06:22:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecUkO-0007Xh-V0 for help-gnu-emacs@gnu.org; Fri, 19 Jan 2018 06:22:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecUkL-0002Ur-MW for help-gnu-emacs@gnu.org; Fri, 19 Jan 2018 06:22:12 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:38094) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ecUkL-0002TP-Cg for help-gnu-emacs@gnu.org; Fri, 19 Jan 2018 06:22:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=20171004; h=From:In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:Date; bh=8AoEM33OKUgWEKrmovON0qsmK1uKIDWdUjWlZ6rf9WA=; b=VzJzUas5Run7vR0LWVqJh6c1HvOx6oA+ENoBqsKPL+kAk3CzH1jMVSzj5OnYChQF63DWgkStXMz6VLxi9ObIuBoltFJlHRwnxzPHKgC0UlEh5RwykfGAdHNrTa29NhOm3KbEFn8UCwxI6FicEG7uTwTfoqYQbfmjYYvRKxsoIWRRySu44lZRmTv2CNmcrlsQMOtGepXBFiy1/vKBvX7XqNJHkkavZhyULaQuBN01BWPcMc0C/W3Insdz3L/t4YyWAYdvvXbgYsOhaCOlNplyONEnASci2yVqNoYT8OsfP8BwDN9B+t8KQxxiFaNq/O0PdDt91XGb0Lf2voaSN8K9lA==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1ecUkK-0003OX-3Z; Fri, 19 Jan 2018 12:22:08 +0100 In-Reply-To: <86k1we2kh0.fsf@zoho.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 5.199.139.25 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115793 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jan 19, 2018 at 11:47:55AM +0100, Emanuel Berg wrote: > tomas wrote: > > > I'm actually enhancing one I wrote for > > a customer ten years ago (C, GTK2). I have > > written many of those. And I'm far from > > a special snowflake. > > Yes, I have also written them (in C and C++) > but never thought it to be really common and > even Emacs does it in a poor-man's way compared > to Unix. No. It delegates this stuff to the OS, which is (most of the time) the Right Thing to Do. > If a process cannot even be preempted It can be preempted, see signal. But even if you want to get signals right, the most straightforward way is to queue the event to take care of it at a point where your program is ready to deal with it. An operating system basically does the same. No magic here, either. > one might > as well extend the definition of "scheduling" to > a OO game loop that progresses the animation > state of a bunch of sprites in a linked list... Everyone does it that way. Whether you use a linked list or (forced by priorities) a red-black tree or a heap doesn't change the basic concept. I once had a program collecting messages from SCADA systems. I started with a linked list for events and told the customer it would hold up for about 1000 sensors in the field. Then he came back with... 10K sensors. I had to change to a heap implementation. > > It's not magic. It's pretty "classical" as > > Unix goes > > With Unix we think rather of PCBs, IPC, context > switches, memory protection, different > scheduling algorithms, on-the-fly and > from-the-outside changes of priorities, and > so on. You try to delegate that to the OS: that's what it is for. Even modern browsers, which have a dire need for memory protection, just have separate processes for that. After all, I don't want even to think how to manage things like the MMU from user space. Dragons is not even an adequate description for that. Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlph1OAACgkQBcgs9XrR2kYgfgCfX2bEEoSAIQ014GI4N++2S2Q/ e58An0xhCRL4wbHg2BsvdiA3q7Z7bhgb =TUck -----END PGP SIGNATURE-----