* try-this-for ? @ 2018-01-17 21:04 Emanuel Berg 2018-01-17 23:50 ` John Mastro ` (3 more replies) 0 siblings, 4 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-17 21:04 UTC (permalink / raw) To: help-gnu-emacs Is there something like this: (try-this-for SECONDS BODY) If BODY hasn't completed after SECONDS, everything will be aborted, i.e. the equivalence of `keyboard-quit' (or whatever appropriate). But what has already happened until the point of abortion don't have to be rolled back or any state restored or dumped or anything like that. If BODY do complete before SECONDS it should be transparent in the sense that what should be returned is the final evaluation of BODY. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-17 21:04 try-this-for ? Emanuel Berg @ 2018-01-17 23:50 ` John Mastro 2018-01-18 2:08 ` Bob Newell ` (2 subsequent siblings) 3 siblings, 0 replies; 20+ messages in thread From: John Mastro @ 2018-01-17 23:50 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <moasen@zoho.com> wrote: > Is there something like this: > > (try-this-for SECONDS BODY) > > If BODY hasn't completed after SECONDS, > everything will be aborted, i.e. > the equivalence of `keyboard-quit' (or whatever > appropriate). > > But what has already happened until the point > of abortion don't have to be rolled back or any > state restored or dumped or anything like that. > > If BODY do complete before SECONDS it should be > transparent in the sense that what should be > returned is the final evaluation of BODY. There's `with-timeout' in timer.el, however (from the docstring): The timeout is checked whenever Emacs waits for some kind of external event (such as keyboard input, input from subprocesses, or a certain time); if the program loops without waiting in any way, the timeout will not be detected. So it may not be exactly what you want. John ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-17 21:04 try-this-for ? Emanuel Berg 2018-01-17 23:50 ` John Mastro @ 2018-01-18 2:08 ` Bob Newell [not found] ` <mailman.7535.1516241346.27995.help-gnu-emacs@gnu.org> [not found] ` <mailman.7534.1516233062.27995.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 20+ messages in thread From: Bob Newell @ 2018-01-18 2:08 UTC (permalink / raw) To: help-gnu-emacs > (try-this-for SECONDS BODY) The best way to do this is to build the timer check into 'body' itself. That way you can be sure to always exit in a known state. If an external timer interrupts 'body' (and I haven't yet figured out how to do that, so it's in theory) then the state could be in some disorder. Of course if 'body' is something like an internal emacs call that simply might run for a long time, this idea won't work. If 'body' is running a /process/, however, an Emacs timer can trigger a call to 'kill-process' or 'interrupt-process' to halt the process. Don't know if any of this helps ... -- Bob Newell Honolulu, Hawai`i Sent via Linux Mint 17. ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7535.1516241346.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7535.1516241346.27995.help-gnu-emacs@gnu.org> @ 2018-01-18 2:52 ` Emanuel Berg 0 siblings, 0 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 2:52 UTC (permalink / raw) To: help-gnu-emacs Bob Newell wrote: > If 'body' is running a /process/, however, an > Emacs timer can trigger a call to > 'kill-process' or 'interrupt-process' to halt > the process. But this only works for Unix processes, the equivalent of doing $ program & $ # ... $ pkill -9 program in the shell, right? Can one do this for arbitrary Elisp in/from Emacs? If so, how? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7534.1516233062.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7534.1516233062.27995.help-gnu-emacs@gnu.org> @ 2018-01-18 2:56 ` Emanuel Berg 2018-01-18 9:27 ` tomas [not found] ` <mailman.7540.1516267658.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 2:56 UTC (permalink / raw) To: help-gnu-emacs John Mastro wrote: > There's `with-timeout' in timer.el, however > (from the docstring): > > The timeout is checked whenever Emacs waits > for some kind of external event (such as > keyboard input, input from subprocesses, or > a certain time); if the program loops without > waiting in any way, the timeout will not > be detected. Right, I suspected that... so what I ask for perhaps cannot be done because of the very architecture? There is no preemption, only collaboration? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 2:56 ` Emanuel Berg @ 2018-01-18 9:27 ` tomas [not found] ` <mailman.7540.1516267658.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 20+ messages in thread From: tomas @ 2018-01-18 9:27 UTC (permalink / raw) To: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 18, 2018 at 03:56:44AM +0100, Emanuel Berg wrote: [...] > Right, I suspected that... so what I ask for > perhaps cannot be done because of the very > architecture? There is no preemption, > only collaboration? There be dragons. Or dragons and mad cows. Up to now, Emacs Lisp's model of concurrency seems to be explicitly cooperative. The two spots in the manual to start with ("Special Events" [0] and, in a more modern Emacs version "Threads" [1] hint at this. Currently it seems to be a basic limitation of the interpreter, although the verbiage in [1] suggests that there is an active will to change that. So if you want to get "signals" right deep in your search for the next Mersenne prime, you'll have to embed some form of "yield" [2] in your calculation. But if you alre already "yielding" at strategic spots in your Mersenne quest, you can as well consult your watch (i.e. give the timer functions a chance to run), so you don't need signals, threads or other exotica for that [3]. Believe me, this is the easier part, and if you plan carefully and develop some sense of aesthetics it comes about pretty organically. The dragons are elsewhere. Cows? I never said anything about them, oh, no. Cheers [0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Special-Events.html#Special-Events [1] http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/lispref/threads.texi?h=emacs-26 [2] https://en.wikipedia.org/wiki/Generator_(computer_programming) [3] What do I need threads for, then? For one, if you want to wield more computing power in one process: remember, the box you bought has at least two cores, and each core not dedicated to Emacs is one core wasted. - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpgaHwACgkQBcgs9XrR2kaDXwCdGWfdXn/4Ymm83RKSwzX8/7hl 4IoAn3ZiADkHIlI+YeU2YJV2dj6XdEsw =3VTm -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7540.1516267658.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7540.1516267658.27995.help-gnu-emacs@gnu.org> @ 2018-01-18 12:00 ` Emanuel Berg 2018-01-18 12:03 ` Emanuel Berg ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 12:00 UTC (permalink / raw) To: help-gnu-emacs tomas wrote: > Up to now, Emacs Lisp's model of concurrency > seems to be explicitly cooperative. "seems to be explicitly" :) ? True concurrency isn't possible even for multicore architectures IIUC. The perceived concurrency, how does that work if it isn't Unix-style preemptive with priorities and a scheduler etc.? For example, with `list-processes', is that really all cooperative stuff handled by the idle timer? I thought the idle timer did font lock and such lightweight not-really-necessary background work whenever it got the chance, however that must be something else as it isn't listed. By the way, if Emacs cannot preempt, when the idle timer does background work during a lack-of-input respite, does that mean, when you start typing again, the background work isn't preempted either, only it is programmed like (when t (do-something step-1) (check-if-OK-to-continue) ; ... (do-something step-n) ) so despite not being preemptable, perceived concurrency is achieved as everything is so fast anyway? > For one, if you want to wield more computing > power in one process: remember, the box you > bought has at least two cores, and each core > not dedicated to Emacs is one core wasted. I remember writing a post on this very list how to dedicate one core entirely to Emacs! It must be lost somewhere in the archives. What I remember it made Emacs run slightly faster :) I guess one can achieve virtually the same with nice(1) and/or not running anything else :)) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 12:00 ` Emanuel Berg @ 2018-01-18 12:03 ` Emanuel Berg 2018-01-18 12:11 ` Emanuel Berg 2018-01-18 12:43 ` tomas [not found] ` <mailman.7544.1516279427.27995.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 12:03 UTC (permalink / raw) To: help-gnu-emacs By the way, did anyone try to do a "Unemacs" merging the POSIX process model with Emacs which with no disrespect seems to be beyond comparison more powerful than the idle timer stuff. Actually they aren't mutually exclusive as the idle timer stuff can be incorporated/rebranded as "soft real time" :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 12:03 ` Emanuel Berg @ 2018-01-18 12:11 ` Emanuel Berg 0 siblings, 0 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 12:11 UTC (permalink / raw) To: help-gnu-emacs > POSIX If you didn't know it, "Portable Operating System Interface", ~1985. The X is for Unix and the acronym was suggested by Richard Stallman. The former designation was IEEE-IX so no wonder they dropped it :) One has to wonder about the "P" tho as it seems portability is sort of the reason for any standard - if it isn't portable, it isn't a standard but a manual, right? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 12:00 ` Emanuel Berg 2018-01-18 12:03 ` Emanuel Berg @ 2018-01-18 12:43 ` tomas 2018-01-18 15:14 ` Eli Zaretskii [not found] ` <mailman.7544.1516279427.27995.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 20+ messages in thread From: tomas @ 2018-01-18 12:43 UTC (permalink / raw) To: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 18, 2018 at 01:00:49PM +0100, Emanuel Berg wrote: > tomas wrote: > > > Up to now, Emacs Lisp's model of concurrency > > seems to be explicitly cooperative. > > "seems to be explicitly" :) ? (seems to be (explicitly cooperative)) With explicitly I meant that control is not taken away behind a process's back, but the process has to explicitly yield control. > True concurrency isn't possible even for > multicore architectures IIUC. To a certain extent yes: the processors/cores have to cooperate to access common resources (e.g. memory), but as long as they are operating e.g. from local cache they do run in parallel. > The perceived concurrency, how does that work > if it isn't Unix-style preemptive with > priorities and a scheduler etc.? As far as I know, the only (implicit) yield point in Emacs is the event loop, but many things fit in there: waiting for key events, waiting for file descriptors to become readable/writable (e.g. communicating with (operating system) subprocesses, reacting to POSIX signals, the idle timer, etc. > For example, with `list-processes', is that > really all cooperative stuff handled by the > idle timer? Not really the idle timer: this one is (probably?) triggered from the central event loop, as the others. But the great Eli has answered that already in emacs devel some moons ago [1]. Turns out that what I call "event loop" is called the "input queue". If you have a lengthy calculation and want the other things (user input, but also file notifications, communication via sockets, etc) to "keep running", you have to explicitly (that's the "explicit" part in what I labeled as "explicitly cooperative") give a chance to this input queue to run from time to time. Perhaps (sit-for 0) is your friend (it would trigger a redisplay), perhaps something else. Cheers [1] https://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00922.html - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpglnkACgkQBcgs9XrR2kbsIwCfXg9pI1PRDrdljTab+Tuf6VJU /BcAn0IplpC0UqNCPzfcOqcpW0Nd7034 =+CsX -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 12:43 ` tomas @ 2018-01-18 15:14 ` Eli Zaretskii 2018-01-18 15:23 ` tomas 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2018-01-18 15:14 UTC (permalink / raw) To: help-gnu-emacs > Date: Thu, 18 Jan 2018 13:43:37 +0100 > From: <tomas@tuxteam.de> > > As far as I know, the only (implicit) yield point > in Emacs is the event loop, but many things fit > in there: waiting for key events, waiting for file > descriptors to become readable/writable (e.g. > communicating with (operating system) subprocesses, > reacting to POSIX signals, the idle timer, etc. The yield point is actually the pselect call (and its emulations on non-Posix platforms). On the Lisp level, this means waiting for any kind of input: from user (keyboard/mouse), subprocesses (including explicit calls to accept-process-output), network and serial connections, etc. > But the great Eli has answered that already I'll leave the "great" part on your conscience, but regardless, AFAIR Emanuel has me on his kill-file, so mentioning my posts won't help him. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 15:14 ` Eli Zaretskii @ 2018-01-18 15:23 ` tomas 0 siblings, 0 replies; 20+ messages in thread From: tomas @ 2018-01-18 15:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 18, 2018 at 05:14:18PM +0200, Eli Zaretskii wrote: > The yield point is actually the pselect call (and its emulations on > non-Posix platforms). On the Lisp level, this means waiting for any > kind of input: from user (keyboard/mouse), subprocesses (including > explicit calls to accept-process-output), network and serial > connections, etc. Thanks for this lucid explanation: it corresponds more or less to my mental model, but knowing is better than some hunch around the belly. > I'll leave the "great" part on your conscience My conscience is clean (in this regard, that is). > but regardless, AFAIR > Emanuel has me on his kill-file, so mentioning my posts won't help > him. Hm. He's missing out a lot, then. Cheers and thanks - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpgu+sACgkQBcgs9XrR2kaLcgCfbxW1uieqFBDgNeSfDhxiflOV VHgAn3htWNrbBexFMTzJMjIz8JYxX4Zf =Ehh7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7544.1516279427.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7544.1516279427.27995.help-gnu-emacs@gnu.org> @ 2018-01-18 12:59 ` Emanuel Berg 2018-01-18 13:16 ` tomas [not found] ` <mailman.7546.1516281409.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 12:59 UTC (permalink / raw) To: help-gnu-emacs tomas wrote: >> True concurrency isn't possible even for >> multicore architectures IIUC. > > To a certain extent yes: the processors/cores > have to cooperate to access common resources > (e.g. memory), but as long as they are > operating e.g. from local cache they do run > in parallel. Yes, but I meant with respect to Emacs, can one have, for example (let*((value-one (compute it)) ; on CPU1 (value-two (compute it)) )) ; on CPU2 execute in parallel? > central event loop Is this the KERNEL? > to "keep running", you have to explicitly > (that's the "explicit" part in what I labeled > as "explicitly cooperative") give a chance to > this input queue to run from time to time. > Perhaps (sit-for 0) is your friend (it would > trigger a redisplay), perhaps something else The problem with yielding is it won't work to interrupt something that has put Emacs into a hanged state... -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 12:59 ` Emanuel Berg @ 2018-01-18 13:16 ` tomas [not found] ` <mailman.7546.1516281409.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 20+ messages in thread From: tomas @ 2018-01-18 13:16 UTC (permalink / raw) To: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 18, 2018 at 01:59:17PM +0100, Emanuel Berg wrote: > tomas wrote: > > >> True concurrency isn't possible even for > >> multicore architectures IIUC. > > > > To a certain extent yes: the processors/cores > > have to cooperate to access common resources > > (e.g. memory), but as long as they are > > operating e.g. from local cache they do run > > in parallel. > > Yes, but I meant with respect to Emacs, can one > have, for example > > (let*((value-one (compute it)) ; on CPU1 > (value-two (compute it)) )) ; on CPU2 > > execute in parallel? No, but see threads: they *can* execute on different CPUs (whether Emacs will give you control over that is another question; moreover it's a pretty new feature anyway). > > central event loop > > Is this the KERNEL? No, I was talkint about Emacs input queue. > > to "keep running", you have to explicitly [...] > The problem with yielding is it won't work to > interrupt something that has put Emacs into > a hanged state... That's true about most programs out there. Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpgnjgACgkQBcgs9XrR2ka8RgCdFeu2XIJvDaOMwyIGsUWD2Tn+ H50An3aXGw2SOr1o1mk6/uUbsUwwdEu7 =I0xt -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7546.1516281409.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7546.1516281409.27995.help-gnu-emacs@gnu.org> @ 2018-01-18 22:44 ` Emanuel Berg 2018-01-19 8:38 ` tomas [not found] ` <mailman.7613.1516351115.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-18 22:44 UTC (permalink / raw) To: help-gnu-emacs tomas wrote: >> The problem with yielding is it won't work >> to interrupt something that has put Emacs >> into a hanged state... > > That's true about most programs out there. Except for one: Unix. PS. Regarding KILL files, conflicts due to cabin fever and sleep deprivation left a terrible hangover at the time but not even my hangovers last almost a decade, and besides I already posted a post saying I was forgiving everyone including myself. This was 6-8y ago. Today I try not to deal with guilt/apologies whatsoever anymore but at the time it was genuine. If anyone didn't read it maybe it was because I was still in their KILL files :) Ha ha ha! But anyway I have no desire to re-live any of that so as the saying goes, altho I always think it sounds a silly thing to say, "this is the last thing I'll say about it". PPS. With Gnus, we recommend *scoring* instead of killing. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-18 22:44 ` Emanuel Berg @ 2018-01-19 8:38 ` tomas [not found] ` <mailman.7613.1516351115.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 20+ messages in thread From: tomas @ 2018-01-19 8:38 UTC (permalink / raw) To: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 18, 2018 at 11:44:00PM +0100, Emanuel Berg wrote: > tomas wrote: > > >> The problem with yielding is it won't work > >> to interrupt something that has put Emacs > >> into a hanged state... > > > > That's true about most programs out there. Woah. Communication is difficult. I meant "user space programs" in the context of Unix (more precisely: an unixoid operating system). More specifically I meant "practical, useful programs" and not proofs-of-concepts. Cheers - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlphroQACgkQBcgs9XrR2kaN8QCfSP2EZs+KXqql3RAANNFEZcKM gzIAnRLf8LLS+jGMCsWlpZk0UNM+gzKr =0X+a -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7613.1516351115.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7613.1516351115.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 8:55 ` Emanuel Berg 2018-01-19 9:25 ` tomas [not found] ` <mailman.7614.1516353949.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 20+ messages in thread From: Emanuel Berg @ 2018-01-19 8:55 UTC (permalink / raw) To: help-gnu-emacs tomas wrote: > I meant "user space programs" in the context > of Unix (more precisely: an unixoid operating > system). More specifically I meant > "practical, useful programs" and not > proofs-of-concepts. OK, but do you really have that many user space programs that does scheduling? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-19 8:55 ` Emanuel Berg @ 2018-01-19 9:25 ` tomas [not found] ` <mailman.7614.1516353949.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 20+ messages in thread From: tomas @ 2018-01-19 9:25 UTC (permalink / raw) To: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jan 19, 2018 at 09:55:35AM +0100, Emanuel Berg wrote: > tomas wrote: > > > I meant "user space programs" in the context > > of Unix (more precisely: an unixoid operating > > system). More specifically I meant > > "practical, useful programs" and not > > proofs-of-concepts. > > OK, but do you really have that many user space > programs that does scheduling? 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. Every interactive program (worth its salt) does scheduling. Every server which has to juggle different client requests (web server, database server, ssh daemon, you name it). In my current case, it's a GUI program. I want it to be responsive to the user, but concurrently listen to database notifications, send requests to the database and to an LDAP server, and asynchronously wait for their responses (that is: not block the GUI while doing so). At the same time it is polling an RFID card reader hung on a serial interface -- every 500 ms or so please look for it, again, without glitching the GUI or missing a database notification. Pretty standard fare, and the model isn't that different of what Emacs does or Exim or lighttpd. Under an unixoid, it reduces to watching a bunch of file descriptors using one of the asynchronous interfaces offered to you by your trusty operating system interface (select, poll, epoll, perhaps AIO if you're fancy), thinking hard about whether you need some prioritization (your life is way easier if you don't) and keeping things well organized. You notice when you don't :-) It's not magic. It's pretty "classical" as Unix goes, perhaps like [1]. Cheers [1] https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Unix_Environment - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlphuZUACgkQBcgs9XrR2kby+QCfQOaumMt53kx3jqxMXUOkbFtA dgAAn1zpnkaq3e8vizynQUkAf5GIuILz =cKCH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <mailman.7614.1516353949.27995.help-gnu-emacs@gnu.org>]
* Re: try-this-for ? [not found] ` <mailman.7614.1516353949.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 10:47 ` Emanuel Berg 2018-01-19 11:22 ` tomas 0 siblings, 1 reply; 20+ messages in thread From: Emanuel Berg @ 2018-01-19 10:47 UTC (permalink / raw) To: help-gnu-emacs 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. If a process cannot even be preempted 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... > 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. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: try-this-for ? 2018-01-19 10:47 ` Emanuel Berg @ 2018-01-19 11:22 ` tomas 0 siblings, 0 replies; 20+ messages in thread From: tomas @ 2018-01-19 11:22 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-01-19 11:22 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-17 21:04 try-this-for ? Emanuel Berg 2018-01-17 23:50 ` John Mastro 2018-01-18 2:08 ` Bob Newell [not found] ` <mailman.7535.1516241346.27995.help-gnu-emacs@gnu.org> 2018-01-18 2:52 ` Emanuel Berg [not found] ` <mailman.7534.1516233062.27995.help-gnu-emacs@gnu.org> 2018-01-18 2:56 ` Emanuel Berg 2018-01-18 9:27 ` tomas [not found] ` <mailman.7540.1516267658.27995.help-gnu-emacs@gnu.org> 2018-01-18 12:00 ` Emanuel Berg 2018-01-18 12:03 ` Emanuel Berg 2018-01-18 12:11 ` Emanuel Berg 2018-01-18 12:43 ` tomas 2018-01-18 15:14 ` Eli Zaretskii 2018-01-18 15:23 ` tomas [not found] ` <mailman.7544.1516279427.27995.help-gnu-emacs@gnu.org> 2018-01-18 12:59 ` Emanuel Berg 2018-01-18 13:16 ` tomas [not found] ` <mailman.7546.1516281409.27995.help-gnu-emacs@gnu.org> 2018-01-18 22:44 ` Emanuel Berg 2018-01-19 8:38 ` tomas [not found] ` <mailman.7613.1516351115.27995.help-gnu-emacs@gnu.org> 2018-01-19 8:55 ` Emanuel Berg 2018-01-19 9:25 ` tomas [not found] ` <mailman.7614.1516353949.27995.help-gnu-emacs@gnu.org> 2018-01-19 10:47 ` Emanuel Berg 2018-01-19 11:22 ` tomas
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.