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

Groups > comp.lang.forth > #14375 > unrolled thread

Non-blocking asynchronous execution

Back to article view | Back to comp.lang.forth

Contents

  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

Page 1 of 2  [1] 2  Next page →

#14375 — Non-blocking asynchronous execution

Dear Forthers, 

I came across this interesting talk recently: 

http://www.youtube.com/watch?v=jo_B4LTHi3I

One thing that interested me in the talk is node.js' non-blocking, 
asynchronous execution model without using threads. I believe Erlang uses 
something like this. How would you accomplish it using your Forth? Eg, 

: set-timeout ( xtCallback timeMillisec  --  )  ... ; 

: greeting ." Hello World " . ; 
: greeting2 ." Goodbye World " . ; 

' greeting 5000 set-timeout 
greeting2

Goodbye World ok <-- occurs immediately 
Hello World ok  <-- occurs after 5 seconds have elapsed. 

Ie, SET-TIMEOUT schedules its callback for execution at the predefined 
time interval without blocking.  

Cheers,
Arnold

[toc] | [next] | [standalone]

#14376

On Jul 25, 4:50 pm, Arnold Doray <inva...@invalid.com> wrote:
> Dear Forthers,
>
> I came across this interesting talk recently:
>
> http://www.youtube.com/watch?v=jo_B4LTHi3I
>
> One thing that interested me in the talk is node.js' non-blocking,
> asynchronous execution model without using threads. I believe Erlang uses
> something like this. How would you accomplish it using your Forth? Eg,
>
> : set-timeout ( xtCallback timeMillisec  --  )  ... ;
>
> : greeting ." Hello World " . ;
> : greeting2 ." Goodbye World " . ;
>
> ' greeting 5000 set-timeout
> greeting2
>
> Goodbye World ok <-- occurs immediately
> Hello World ok  <-- occurs after 5 seconds have elapsed.
>
> Ie, SET-TIMEOUT schedules its callback for execution at the predefined
> time interval without blocking.
>
> Cheers,
> Arnold

I would have thought this would be quite easy on any multi-tasking
Forth system.

Blocking is inevitable however once system resources (I/o) enters the
mix.

[toc] | [prev] | [next] | [standalone]

#14402

On Wed, 25 Jul 2012 09:09:32 -0700, Mark Wills wrote:
> 
> I would have thought this would be quite easy on any multi-tasking Forth
> system.

Tantalizing. Could you elaborate?

> 
> Blocking is inevitable however once system resources (I/o) enters the
> mix.

Yes, for that task waiting on I/O, but the program itself need not block. 

[toc] | [prev] | [next] | [standalone]

#14385

On Wednesday, July 25, 2012 11:50:32 AM UTC-4, Arnold Doray wrote:
> Dear Forthers, 
> 
> I came across this interesting talk recently: 
> 
> http://www.youtube.com/watch?v=jo_B4LTHi3I
> 
> One thing that interested me in the talk is node.js' non-blocking, 
> asynchronous execution model without using threads. I believe Erlang uses 
> something like this. How would you accomplish it using your Forth? Eg, 
> 
> : set-timeout ( xtCallback timeMillisec  --  )  ... ; 
> 
> : greeting ." Hello World " . ; 
> : greeting2 ." Goodbye World " . ; 
> 
> ' greeting 5000 set-timeout 
> greeting2
> 
> Goodbye World ok <-- occurs immediately 
> Hello World ok  <-- occurs after 5 seconds have elapsed. 
> 
> Ie, SET-TIMEOUT schedules its callback for execution at the predefined 
> time interval without blocking.  
> 
> Cheers,
> Arnold

I've always had a hard time remembering what the term "blocking" and "non-blocking" means because the term does not indicate what is being blocked or not.  In this case I assume you are talking about sharing a single processor between multiple processes and the terms refer to the CPU being blocked or not blocked for execution of other processes?  

I am working with multiple processors so I don't have that problem.  Each processor does one thing, does it well and then waits for the other processor to feed it some more data.  This is the data flow model.  

Rick

[toc] | [prev] | [next] | [standalone]

#14403

On Wed, 25 Jul 2012 14:41:13 -0700, rickman wrote:

> 
> I've always had a hard time remembering what the term "blocking" and
> "non-blocking" means because the term does not indicate what is being
> blocked or not.  In this case I assume you are talking about sharing a
> single processor between multiple processes and the terms refer to the
> CPU being blocked or not blocked for execution of other processes?
> 

A program is made up of many tasks. 

"non-blocking" means a task does not "block" (prevented from being 
executed) just because a preceding task did (say waiting on I/O). 

> I am working with multiple processors so I don't have that problem. 
> Each processor does one thing, does it well and then waits for the other
> processor to feed it some more data.  This is the data flow model.
> 
> Rick

So, if a task blocks on I/O, its CPU is idle? That seems to me to be a 
horrible waste of resources. 

[toc] | [prev] | [next] | [standalone]

#14406

Arnold Doray <invalid@invalid.com> writes:
>> I am working with multiple processors so I don't have that problem. 
> So, if a task blocks on I/O, its CPU is idle? That seems to me to be a 
> horrible waste of resources. 

I think Rick is talking about the GA144, which has more CPU's than
anyone has figured out how to use, as far as I can tell.  The resource
it tries most to conserve is power.  When a GA144 CPU is blocked or
idle, it consumes essentially no power, so in that sense it is
resource-efficient.

[toc] | [prev] | [next] | [standalone]

#14389

On Wednesday, July 25, 2012 10:50:32 AM UTC-5, Arnold Doray wrote:
> Dear Forthers, 
> 
> I came across this interesting talk recently: 
> 
> http://www.youtube.com/watch?v=jo_B4LTHi3I
> 
> One thing that interested me in the talk is node.js' non-blocking, 
> asynchronous execution model without using threads. I believe Erlang uses 
> something like this. How would you accomplish it using your Forth? Eg, 
> 
> : set-timeout ( xtCallback timeMillisec  --  )  ... ; 
> 
> : greeting ." Hello World " . ; 
> : greeting2 ." Goodbye World " . ; 
> 
> ' greeting 5000 set-timeout 
> greeting2
> 
> Goodbye World ok <-- occurs immediately 
> Hello World ok  <-- occurs after 5 seconds have elapsed. 
> 
> Ie, SET-TIMEOUT schedules its callback for execution at the predefined 
> time interval without blocking.  
> 
> Cheers,
> Arnold


Below is one way to do it in kForth, using POSIX signals.

Krishna

--

\ Example of Asynchronous Delayed Execution in kForth
\ Using POSIX signals.

include signal

variable xtDelay

: delayed-word ( -- )
    xtDelay @ execute
    SIG_IGN SIGALRM  forth-signal  DROP  \ Stop sending SIGALRM
;
    
: set-timeout ( xtCallback timeMillisec -- )
    swap xtDelay !
    ['] delayed-word SIGALRM   forth-signal  drop
    dup  SET-TIMER     \ Send SIGALRM to kForth at specified interval
;

: greeting  ." Hello World" ;
: greeting2 ." Goodbye World" ;

' greeting 5000 set-timeout
greeting2

[toc] | [prev] | [next] | [standalone]

#14396

krishna.myneni@ccreweb.org writes:
> Below is one way to do it in kForth, using POSIX signals. ...
>     ['] delayed-word SIGALRM   forth-signal  drop
>     dup  SET-TIMER     \ Send SIGALRM to kForth at specified interval

This isn't too useful since you're only allowed to have one SIGALRM
pending at any time.  If you want multiple pending timeouts you need a
user level timeout queue, preferably using a fast data structure if the
number of timeouts is potentially large.

Here's a paper about how GHC does it:

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36841.pdf

[toc] | [prev] | [next] | [standalone]

#14399

On Wednesday, July 25, 2012 7:22:23 PM UTC-5, Paul Rubin wrote:
> krishna myneni writes:
> > Below is one way to do it in kForth, using POSIX signals. ...
> >     ['] delayed-word SIGALRM   forth-signal  drop
> >     dup  SET-TIMER     \ Send SIGALRM to kForth at specified interval
> 
> This isn't too useful since you're only allowed to have one SIGALRM
> pending at any time.  If you want multiple pending timeouts you need a
> user level timeout queue, preferably using a fast data structure if the
> number of timeouts is potentially large.
> 
> Here's a paper about how GHC does it:
> 
> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36841.pdf


Is there some disadvantage of a user-level queue, e.g.

' word1 1000 set-timeout
' word2 2000 set-timeout
\ ...
start-timeout

where SET-TIMEOUT adds the entries in a table, and START-TIMEOUT kicks off the setup of the SIGALRM handler and the timer for the first xt in the table. The handler, which in my example was the word DELAYED-WORD would then execute the first xt, lookup the next entry in the table and set its xt and reset the timer signal to the difference in times between that entry and its previous one. Seems pretty easy and flexible to handle at the user level.

Krishna
 

[toc] | [prev] | [next] | [standalone]

#14404

On Wed, 25 Jul 2012 18:22:42 -0700, krishna.myneni wrote:

> Is there some disadvantage of a user-level queue, e.g.
> 
> ' word1 1000 set-timeout
> ' word2 2000 set-timeout
> \ ...
> start-timeout
> 
> where SET-TIMEOUT adds the entries in a table, and START-TIMEOUT kicks
> off the setup of the SIGALRM handler and the timer for the first xt in
> the table. The handler, which in my example was the word DELAYED-WORD
> would then execute the first xt, lookup the next entry in the table and
> set its xt and reset the timer signal to the difference in times between
> that entry and its previous one. Seems pretty easy and flexible to
> handle at the user level.
> 
> Krishna

Firstly, I feel that using START-TIMEOUT at the end to kick off the 
scheduling greatly removes the advantage of this style of programming. 
For one, it would not be possible to add scheduled tasks dynamically. 

Second, your solution would fail if a task in the queue blocks because it 
is waiting on I/O. But overcoming this problem is precisely the point of 
this style of programming. 

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#14409

On Wednesday, July 25, 2012 10:03:04 PM UTC-5, Arnold Doray wrote:
> On Wed, 25 Jul 2012 18:22:42 -0700, krishna.myneni wrote:
> 
> > Is there some disadvantage of a user-level queue, e.g.
> > 
> > ' word1 1000 set-timeout
> > ' word2 2000 set-timeout
> > \ ...
> > start-timeout
> > 
> > where SET-TIMEOUT adds the entries in a table, and START-TIMEOUT kicks
> > off the setup of the SIGALRM handler and the timer for the first xt in
> > the table. The handler, which in my example was the word DELAYED-WORD
> > would then execute the first xt, lookup the next entry in the table and
> > set its xt and reset the timer signal to the difference in times between
> > that entry and its previous one. Seems pretty easy and flexible to
> > handle at the user level.
> > 
> > Krishna
> 
> Firstly, I feel that using START-TIMEOUT at the end to kick off the 
> scheduling greatly removes the advantage of this style of programming. 
> For one, it would not be possible to add scheduled tasks dynamically. 
> 

I don't see a problem with scheduling the pseudo-tasks dynamically. SET-TIMEOUT can be executed even after START-TIMEOUT -- the task table can be modified at any point in execution, although care must be taken in selecting the offset time, based on the current time relative to the time of START-TIMEOUT. 

> Second, your solution would fail if a task in the queue blocks because it 
> is waiting on I/O. But overcoming this problem is precisely the point of 
> this style of programming. 
> 

Ok, the assumption is that all pseudo-tasks perform non-blocking I/O. If one of the words in the task-table performs blocking I/O that would completely invalidate this approach. To operate in such a situation, it seems to me that you would need true OS-based multi-tasking. 

Note that other words whose execution doesn't depend on the SIGALRM signal can perform blocking I/O without affecting the operation of the delayed words.

Krishna

[toc] | [prev] | [next] | [standalone]

#14411

On Thu, 26 Jul 2012 00:59:51 -0700, krishna.myneni wrote:

>> 
>> Firstly, I feel that using START-TIMEOUT at the end to kick off the
>> scheduling greatly removes the advantage of this style of programming.
>> For one, it would not be possible to add scheduled tasks dynamically.
>> 
>> 
> I don't see a problem with scheduling the pseudo-tasks dynamically.
> SET-TIMEOUT can be executed even after START-TIMEOUT -- the task table
> can be modified at any point in execution, although care must be taken
> in selecting the offset time, based on the current time relative to the
> time of START-TIMEOUT.
> 

Well, the JS approach does not need it, so for a Forth solution to be 
compelling, that simplicity of use has to be matched or exceeded.

>> Second, your solution would fail if a task in the queue blocks because
>> it is waiting on I/O. But overcoming this problem is precisely the
>> point of this style of programming.
>> 
>> 
> Ok, the assumption is that all pseudo-tasks perform non-blocking I/O. If
> one of the words in the task-table performs blocking I/O that would
> completely invalidate this approach. To operate in such a situation, it
> seems to me that you would need true OS-based multi-tasking.
> 

Well, unfortunately, the whole basis of highly concurrent tasks in this 
context is that most tasks will block on I/O. Think chat servers, web 
servers, etc.

> Note that other words whose execution doesn't depend on the SIGALRM
> signal can perform blocking I/O without affecting the operation of the
> delayed words.

I don't understand --- how can this be done without starting a new thread?

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#14434

This new Google interface seems to be crippled, so I'll have to reply to Arnold's last message without his comments in front of me. Regarding simplicity of use, the Forth signal based version does not require START-TIMEOUT. The first use of SET-TIMEOUT could start the setup of the timer signal.  It's just an implementation detail, I believe. The serious limitation is that the pseudo tasks should complete in a timely manner, so that the next task xt can be setup. There's no way to guarantee this a priori, so this method is only useful for setting up a sequence of fast executing asynchronous, non-blocking pseudo tasks.

With regard to the question of why blocking words which are not pseudo tasks will not interfere with the pseudo task execution, it should be noted that signals are equivalent to a software interrupt for user code. As long as the application (Forth system) has setup a handler for the signal, it will execute even if the currently executing word is performing blocking i/o.

Krishna

[toc] | [prev] | [next] | [standalone]

#14442

On Thu, 26 Jul 2012 11:02:07 -0700, krishna.myneni wrote:

> This new Google interface seems to be crippled, 

Try pan. It's a delight to use. 

> so I'll have to reply to
> Arnold's last message without his comments in front of me. Regarding
> simplicity of use, the Forth signal based version does not require
> START-TIMEOUT. The first use of SET-TIMEOUT could start the setup of the
> timer signal.  It's just an implementation detail, I believe. The
> serious limitation is that the pseudo tasks should complete in a timely
> manner, so that the next task xt can be setup. There's no way to
> guarantee this a priori, so this method is only useful for setting up a
> sequence of fast executing asynchronous, non-blocking pseudo tasks.
> 

I don't think I was clear in my original post -- the real issue is highly 
concurrent non-blocking I/O. The "set-timeout" example was really to 
illustrate non-blocking generally, even for tasks that have no blocking 
IO. 

Also, I don't think hard realtime is the concern. Instead, the issue is 
the ability to efficiently handle millions of connections, the vast 
majority of which will be blocked. 

3 examples from the talk: 

- Servers with "keep-alive" connections, (there could be millions of 
these)
- Servers waiting for a DB response (you want to move on to the next 
request and not block)
- Chat servers. (a combination of the above). 

None of these has true "realtime" requirements. 


> With regard to the question of why blocking words which are not pseudo
> tasks will not interfere with the pseudo task execution, it should be
> noted that signals are equivalent to a software interrupt for user code.
> As long as the application (Forth system) has setup a handler for the
> signal, it will execute even if the currently executing word is
> performing blocking i/o.
> 

I am concerned with blocking pseudo-tasks. 

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#14448

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.

[toc] | [prev] | [next] | [standalone]

#14450

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

[toc] | [prev] | [next] | [standalone]

#14398

Arnold Doray <invalid@invalid.com> writes:
> One thing that interested me in the talk is node.js' non-blocking, 
> asynchronous execution model without using threads. I believe Erlang uses 
> something like this. How would you accomplish it using your Forth? 

Forth traditionally uses cooperative multi-tasking.  The task switcher
runs at i/o operations or when you call a special word called PAUSE.
I've looked at the eforth implementation and it is extremely simple and
fast.  There are many other ones that are basically similar.

I don't remember if eforth has a timeout scheduler but again, it's
old-school, look at an OS book for how to do it.  Basically you have a
queue of pending timeouts, and a periodic timer interrupt, and a task
that wakes up on the timer interrupt to check the timeout queue and wake
up any task that has a timeout due.  If you want to get fancy and handle
a lot of timeouts, you can use various O(log n) or O(1) lookup data
structures to store the timeouts and be able to quickly find the next
pending one, but if you have just a few timeouts you can use a search
list.  I seem to remember that early versions of Linux had an O(n)
scheduler and they eventually replaced it with an O(1) scheduler.

Elsewhere I posted a url for a paper about the GHC scheduler.  I'd
expect Erlang works about the same way.

Node.js is crude by comparison: all the scheduling happens in the user
application, interspersed with the application logic, giving a pattern
called "inversion of control".  Whether that's good or bad is a debate
that has gone on for decades.

[toc] | [prev] | [next] | [standalone]

#14401

On Wed, 25 Jul 2012 17:48:28 -0700, Paul Rubin wrote:

> Forth traditionally uses cooperative multi-tasking.  The task switcher
> runs at i/o operations or when you call a special word called PAUSE.
> I've looked at the eforth implementation and it is extremely simple and
> fast.  There are many other ones that are basically similar.

This isn't about multi-tasking, although that is an interesting problem 
too. It's about scheduling tasks to occur at predefined times in the user 
application. 

> 
> I don't remember if eforth has a timeout scheduler but again, it's
> old-school, look at an OS book for how to do it.  Basically you have a
> queue of pending timeouts, and a periodic timer interrupt, and a task
> that wakes up on the timer interrupt to check the timeout queue and wake
> up any task that has a timeout due.  If you want to get fancy and handle
> a lot of timeouts, you can use various O(log n) or O(1) lookup data
> structures to store the timeouts and be able to quickly find the next
> pending one, but if you have just a few timeouts you can use a search
> list.  I seem to remember that early versions of Linux had an O(n)
> scheduler and they eventually replaced it with an O(1) scheduler.
> 

With a timer thread, you'd still have to start a separate thread to run 
the task; otherwise, the solution would block other scheduled tasks from 
running. I don't think that's what's going on here, I get the impression 
that it is much lighter weight than this, but I could be wrong. 

I'm also ignorant of how to start threads in Forth. Is this 
implementation specific? 

> Elsewhere I posted a url for a paper about the GHC scheduler.  I'd
> expect Erlang works about the same way.
> 

Many thanks for the GHC paper. Erlang claims to be able to schedule 10K 
of lightweight "threads" (not OS threads), and I suppose this is what the 
V8 runtime on which runs node.js does too. Doing something similar in 
Forth is what I am interested in. 

> Node.js is crude by comparison: all the scheduling happens in the user
> application, interspersed with the application logic, giving a pattern
> called "inversion of control".  Whether that's good or bad is a debate
> that has gone on for decades.

Well, there is an explosion of apps using node.js, so the usefulness of 
this approach is being proven practically. But looking at the examples 
presented in the clip, I felt that Forth might be a much better fit. It 
would certainly cut the verbose JS code by quite a bit!

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#14405

On 7/25/12 4:44 PM, Arnold Doray wrote:
> On Wed, 25 Jul 2012 17:48:28 -0700, Paul Rubin wrote:
>
>> Forth traditionally uses cooperative multi-tasking.  The task switcher
>> runs at i/o operations or when you call a special word called PAUSE.
>> I've looked at the eforth implementation and it is extremely simple and
>> fast.  There are many other ones that are basically similar.
>
> This isn't about multi-tasking, although that is an interesting problem
> too. It's about scheduling tasks to occur at predefined times in the user
> application.

Using multiple tasks is actually the easiest way to do that in a 
mutitasked Forth. Each task can run its own timer asynchronously, and do 
what it has to do when the time comes.

Your example introduces the awkwardness of a message being sent to "the 
console". If that's really what you need to do, you'd have to arrange 
some kind of sharing. But in most RL applications when you have a bunch 
of asynchronous tasks scheduled to do various things each has its own 
widgets to manage (or at least you can design your application that way).

>> I don't remember if eforth has a timeout scheduler but again, it's
>> old-school, look at an OS book for how to do it.  Basically you have a
>> queue of pending timeouts, and a periodic timer interrupt, and a task
>> that wakes up on the timer interrupt to check the timeout queue and wake
>> up any task that has a timeout due.  If you want to get fancy and handle
>> a lot of timeouts, you can use various O(log n) or O(1) lookup data
>> structures to store the timeouts and be able to quickly find the next
>> pending one, but if you have just a few timeouts you can use a search
>> list.  I seem to remember that early versions of Linux had an O(n)
>> scheduler and they eventually replaced it with an O(1) scheduler.
>>
>
> With a timer thread, you'd still have to start a separate thread to run
> the task; otherwise, the solution would block other scheduled tasks from
> running. I don't think that's what's going on here, I get the impression
> that it is much lighter weight than this, but I could be wrong.
>
> I'm also ignorant of how to start threads in Forth. Is this
> implementation specific?

Absolutely. It also depends very much on the platform (native, Win, 
*nix, etc.).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#14443

On Wed, 25 Jul 2012 17:26:00 -1000, Elizabeth D. Rather wrote:

>>> Forth traditionally uses cooperative multi-tasking.  The task switcher
>>> runs at i/o operations or when you call a special word called PAUSE.
>>> I've looked at the eforth implementation and it is extremely simple
>>> and fast.  There are many other ones that are basically similar.
>>
>> This isn't about multi-tasking, although that is an interesting problem
>> too. It's about scheduling tasks to occur at predefined times in the
>> user application.
> 
> Using multiple tasks is actually the easiest way to do that in a
> mutitasked Forth. Each task can run its own timer asynchronously, and do
> what it has to do when the time comes.
> 

That sounds like the usual threading model in Java or C. Unfortunately it 
does not scale to millions of threads. I have tried. :) The GHC/Erlang/
node.js runtimes do scale to this level. You can introduce millions of 
tasks (of course, most of these are in a wait state). The overhead to 
create/destroy a thread is also very low. Everything is both "highly 
concurrent" and non-blocking, not just I/O. 

The eye opener for me is realizing (from the node.js talk) how enormously 
popular these highly-concurrent, non-blocking programs are! There are 
node.js programming competitions called "knockouts" that are very well 
attended. So, it seems to me that the need always was there, but waiting 
for an "easy enough" language for large numbers of developers to use. 

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web