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

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

Re: Non-blocking asynchronous execution

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Non-blocking asynchronous execution mhx@iae.nl (Marcel Hendrix) - 2012-07-25 20:08 +0200
    Re: Non-blocking asynchronous execution Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-26 15:03 +0000
      Re: Non-blocking asynchronous execution mhx@iae.nl (Marcel Hendrix) - 2012-07-26 16:39 +0200
        Re: Non-blocking asynchronous execution Arnold Doray <invalid@invalid.com> - 2012-07-27 04:55 +0000

#14380 — Re: Non-blocking asynchronous execution

Arnold Doray <invalid@invalid.com> writes Re: Non-blocking asynchronous execution

[..]

> 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.  

I think something like this iForth/tForth construct will do.

-marcel

FORTH-PROCESS ape
FORTH> : boe  5000 ~MS CR ." Hello World." CR STOP ;   ok
FORTH> : baa  CR ." Goodbye World." ;   ok
FORTH> ' boe RUN ape  baa
Goodbye World. ok
FORTH> ( 5 seconds ... )
Hello World.

[toc] | [next] | [standalone]

#14422

In article <98951510968435@frunobulax.edu>, Marcel Hendrix <mhx@iae.nl> wrote:
>Arnold Doray <invalid@invalid.com> writes Re: Non-blocking asynchronous execution
>
>[..]
>
>> 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.
>
>I think something like this iForth/tForth construct will do.
>
>-marcel
>
>FORTH-PROCESS ape
>FORTH> : boe  5000 ~MS CR ." Hello World." CR STOP ;   ok
>FORTH> : baa  CR ." Goodbye World." ;   ok
>FORTH> ' boe RUN ape  baa
>Goodbye World. ok
>FORTH> ( 5 seconds ... )
>Hello World.

ciforth:
1000 THREAD-PET ape
: boe 5000 MS CR ." The end of the world" CR ;

'boe ape
OK
( 5 seconds ... )
The world ends.

In this and probably Marcels example, during 5 seconds an
extra process shows up on the system. The point is apparently
to accomplish this without the extra process. Hmmm.

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]

#14424

Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: Non-blocking asynchronous execution

[..]

> In this and probably Marcels example, during 5 seconds an
> extra process shows up on the system. The point is apparently
> to accomplish this without the extra process. Hmmm.

No, iForth's FORTH-PROCESS is the classical PAUSE loop with the USER 
areas etc.. It works because *all* iForth I/O is non-blocking. As, 
for accuracy reasons, MS blocks, I had to cheat with the 
non-standard ~MS. As such, I met Arnold's challenge.

You know, I had to look up how FORTH-PROCESS works in the sources. 
How quickly I forget ...

-marcel

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

#14441

On Thu, 26 Jul 2012 16:39:05 +0200, Marcel Hendrix wrote:

> Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: Non-blocking
> asynchronous execution
> 
> [..]
> 
>> In this and probably Marcels example, during 5 seconds an extra process
>> shows up on the system. The point is apparently to accomplish this
>> without the extra process. Hmmm.
> 
> No, iForth's FORTH-PROCESS is the classical PAUSE loop with the USER
> areas etc.. It works because *all* iForth I/O is non-blocking. As,
> for accuracy reasons, MS blocks, I had to cheat with the non-standard
> ~MS. As such, I met Arnold's challenge.
> 
> You know, I had to look up how FORTH-PROCESS works in the sources.
> How quickly I forget ...
> 
> -marcel

I was wrong to say that non-blocking alone is what's required. We really 
need *highly concurrent* non-blocking I/O to meet the demands of what 
node.js developers are doing. Eg, millions of connections/timeouts, which 
are mostly blocked. 

According to the paper Paul pointed me to, the old GHC had non-blocking 
IO but it was comparatively inefficient since it depended on the unix 
select() and pipes. 

The new GHC system uses a few OS threads as I/O managers (one per core), 
Posix's epoll() and data structures in Haskell to keep track of the 
tasks. This proved to be "orders of magnitude" better, enabling GHC to 
handle "tens of millions" of connections/tasks. 

That, and a programming model to match is what I am looking for. 

Cheers,
Arnold

[toc] | [prev] | [standalone]

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

csiph-web