Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #14450
| Newsgroups | comp.lang.forth |
|---|---|
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
| Subject | Re: Non-blocking asynchronous execution |
| Date | 2012-07-27 11:55 +0000 |
| Message-ID | <m7tigx.k6d@spenarnc.xs4all.nl> (permalink) |
| Organization | Dutch Forth Workshop |
| References | <jup4k8$u1a$1@dont-email.me> <7xwr1rs75s.fsf@ruckus.brouhaha.com> <be624740-cf2b-467c-a3bd-31dc62117afa@googlegroups.com> <7xwr1pele1.fsf@ruckus.brouhaha.com> |
In article <7xwr1pele1.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >krishna.myneni@ccreweb.org writes: >> Is there some disadvantage of a user-level queue, e.g. >> >> ' word1 1000 set-timeout >> ' word2 2000 set-timeout \ ... >> where SET-TIMEOUT adds the entries in a table,... > >Well, there's not really a difference between system and user level in >Forth, so one could say it amounts to the same thing, modulo >implementation specifics. > >One issue is that you have to be able to cancel and reset timeouts as >i/o events happen. That means you need some kind of priority structure >to keep track of when the next timeout is supposed to happen, while >letting you add and remove queue entries in arbitrary order. This is a >little bit fancy if you want to handle a lot of timeouts efficiently, >but of course such structures are well known. I wonder if any Forth >multitaskers use them. I don't know of any, but that's really not >saying much. That looks like the note-player in manx. Different parts schedule notes at absolute times, a play-on and a play-off. These are held in a priority queue. There is one high priority task: a busy wait until the first note is to play. If that is a long time off, lower priority tasks - the playing of the parts - run. If the queue is full and the next note to play is a considerable time off, more than 15 ms, the whole manx is rescheduled. This is designed around the premises that the queue can contain everything that is scheduled, no events that pop in at short notice. This is typical Forth type of trade off. Music playing is real time. The precision reached is better than 1 ms on a 90 Mhz Pentium for the typical musical pieces. This example shows what is wrong with the question. We Forthers solve concrete problems, not abstract questions, then look where we could use it. Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-25 15:50 +0000
Re: Non-blocking asynchronous execution Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-25 09:09 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 02:48 +0000
Re: Non-blocking asynchronous execution rickman <gnuarm@gmail.com> - 2012-07-25 14:41 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 02:54 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-25 20:48 -0700
Re: Non-blocking asynchronous execution krishna.myneni@ccreweb.org - 2012-07-25 16:57 -0700
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-25 17:22 -0700
Re: Non-blocking asynchronous execution krishna.myneni@ccreweb.org - 2012-07-25 18:22 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 03:03 +0000
Re: Non-blocking asynchronous execution krishna.myneni@ccreweb.org - 2012-07-26 00:59 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 08:27 +0000
Re: Non-blocking asynchronous execution krishna.myneni@ccreweb.org - 2012-07-26 11:02 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-27 05:09 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-27 00:03 -0700
Re: Non-blocking asynchronous execution Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-27 11:55 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-25 17:48 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 02:44 +0000
Re: Non-blocking asynchronous execution "Elizabeth D. Rather" <erather@forth.com> - 2012-07-25 17:26 -1000
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-27 05:23 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-26 23:24 -0700
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-25 20:56 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-26 08:21 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-26 13:43 -0700
Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-27 04:40 +0000
Re: Non-blocking asynchronous execution Paul Rubin <no.email@nospam.invalid> - 2012-07-26 23:10 -0700
Re: Non-blocking asynchronous execution jim@rainbarrel.com - 2012-07-27 10:41 -0700
csiph-web