Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #14450

Re: Non-blocking asynchronous execution

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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