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 2 of 2 — ← Prev page 1 [2]

#14447

Arnold Doray <invalid@invalid.com> writes:
>> Using multiple tasks is actually the easiest way to do that
> That sounds like the usual threading model in Java or C. Unfortunately it 
> does not scale to millions of threads. I have tried. :) 

The issue there is OS threads, which require kernel context switches and
kilobytes or megabytes of memory per thread, so using them is expensive.
By comparison, Forth multitaskers typically want just a few hundred
bytes per task, or even just a few dozen bytes, and switching is
extremely fast (no cpu context switch).  GHC uses a fancier scheduler
than Forths that I know of, but in principle you could do the same thing
in Forth.

> The GHC/Erlang/ node.js runtimes do scale to this level. You can
> introduce millions of tasks 

Of course Node doesn't do anything with millions of tasks--it has just
one task, that keeps track of all the concurrency manually.  I don't
know what happens if you try to handle millions of connections with
node.  Has anyone done it?

Millions of tasks is pretty unlikely anyway, for real-world servers.
Keep in mind that a TCP port number is 16 bits, so there's a limit of
65k connections per address right there ;-).  In reality, for server
apps, 1000's of tasks (rather than millions) is enouugh for most
purposes, given that the application workload will keep the server busy
with far fewer than millions of connections, if the application is doing
anything interesting.  That's why the old GHC scheduler wasn't usually a
problem in practice, though of course the new one is better.

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

#14407

Arnold Doray <invalid@invalid.com> writes:
> 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. 

Yes, you usually do that by stopping a task, and arranging for it to be
restarted at the desired time by another task (perhaps abstracted into
the language runtime).

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

No, node and v8 do nothing of the sort.  Node doesn't use threads at
all.  It carries all the state of all its concurrent connections in a
single thread, with a user-level dispatch loop figuring out what to do
with each i/o event as it happens.  It's similar to Python's "Twisted
Matrix" package if you're familiar with that.

> Doing something similar in Forth is what I am interested in.

You might look for the article "The C10k problem" if you're interested
in different approaches to high concurrency.

> Well, there is an explosion of apps using node.js, so the usefulness of 
> this approach is being proven practically. 

There's a ton of code being written in Perl and Java too, so maybe those
languages are also practical, but that doesn't save them from being
disgusting ;-).

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

#14410

On Wed, 25 Jul 2012 20:56:14 -0700, Paul Rubin wrote:


>> Doing something similar in Forth is what I am interested in.
> 
> You might look for the article "The C10k problem" if you're interested
> in different approaches to high concurrency.
> 

Thank you for the pointer. The GHC paper is very interesting.

>> Well, there is an explosion of apps using node.js, so the usefulness of
>> this approach is being proven practically.
> 
> There's a ton of code being written in Perl and Java too, so maybe those
> languages are also practical, but that doesn't save them from being
> disgusting ;-).

The proliferation of node.js applications at the very least proves that 
there is a need for this type of app. It is certainly a huge step forward 
from using Java, so I would say that there is merit in the whole 
asynchronous, non-blocking style of programming, at least for this niche.
It might even be the only style suited for situations where highly 
concurrent processing is needed (web servers, chatservers, etc.) 

I think Forth would be a much better fit compared to JS, for this 
programming paradigm. With the addition of a few primitives, or course. 

Cheers
Arnold

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

#14438

Arnold Doray <invalid@invalid.com> writes:
> The proliferation of node.js applications at the very least proves that 
> there is a need for this type of app. 

I'd say it's an artifact of 1) javascript being ubiquitous and fairly
efficient due to the universality of browsers leading to careful
implementations; and 2) the comparative inefficiency of servers that use
OS threads or processes for concurrency.  People like Node because of
its speed even though its programming model sucks.  They can achieve
even higher efficiency with Erlang or GHC, but those are considered nerdy
languages with relatively little uptake compared to Javascript.

Here is a benchmark comparing several servers, where the GHC-based ones
beat Node pretty thoroughly:

http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

> I think Forth would be a much better fit compared to JS, for this 
> programming paradigm. With the addition of a few primitives, or course. 

From what I understand, Forth abandoned the Node concurrency approach
decades ago when it got real multitasking.  

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

#14440

On Thu, 26 Jul 2012 13:43:40 -0700, Paul Rubin wrote:

> Arnold Doray <invalid@invalid.com> writes:
>> The proliferation of node.js applications at the very least proves that
>> there is a need for this type of app.
> 
> I'd say it's an artifact of 1) javascript being ubiquitous and fairly
> efficient due to the universality of browsers leading to careful
> implementations; and 2) the comparative inefficiency of servers that use
> OS threads or processes for concurrency.  People like Node because of
> its speed even though its programming model sucks.  They can achieve
> even higher efficiency with Erlang or GHC, but those are considered
> nerdy languages with relatively little uptake compared to Javascript.
> 
> Here is a benchmark comparing several servers, where the GHC-based ones
> beat Node pretty thoroughly:
> 
> http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-
benchmarks
> 

The benchmark only compares the efficiencies of the runtimes -- GHC 
recently changed their scheduling internals (the paper you yourself 
pointed me to). node.JS could conceivably get the same boost if Google 
upgraded their V8 runtime. 

But that's neither here not there. IMHO, Haskell is hard to program in. 
Whether this is an inherent problem with the language or due to cultural 
bias is hard to say -- but surely the latter has to both be addressed by 
the language? I don't think it has to do with "nerdiness" (by which you 
mean cognitive distance from C/Algol languages?). Languages like Clojure 
seem to be popular -- much more so -- compared to Haskell. Ditto, for 
Erlang -- check out the comments of the creator of CouchDB, probably the 
most well known recent Erlang product: 

http://damienkatz.net/2008/03/what_sucks_abou.html


>> I think Forth would be a much better fit compared to JS, for this
>> programming paradigm. With the addition of a few primitives, or course.
> 
> From what I understand, Forth abandoned the Node concurrency approach
> decades ago when it got real multitasking.


I'm *not* advocating the Node.JS style of doing things -- just that:

1) There is a real "felt need" for highly concurrent non-blocking I/O. 

2) That the Node.js approach is the simplest I've seen to date. I've used 
the new IO in Java, and it is hard to use well. Nowhere near the 
simplicity of node.js. If there is a "better way", as you claim, then do 
share!  

3) I believe that Forth could greatly simplify the style of programming 
that node.js takes (using callbacks, etc), if only superficially due to 
syntax.  

Thanks,
Arnold

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

#14446

Arnold Doray <invalid@invalid.com> writes:
> The benchmark only compares the efficiencies of the runtimes -- GHC 
> recently changed their scheduling internals (the paper you yourself 
> pointed me to). node.JS could conceivably get the same boost if Google 
> upgraded their V8 runtime. 

Not possible without drastically redefining node, IMHO.  Node is
inherently single threaded; GHC and Erlang programs can run on multiple
cores in parallel.  Erlang programs can even run on multiple physically
separate computers.  You can distribute an Erlang application across a
whole data center and its built-in failure recovery stuff will keep the
application running even if a computer crashes or catches on fire.
Haskell is getting something like that too, but it's still experimental.

> But that's neither here not there. IMHO, Haskell is hard to program in. 
> Whether this is an inherent problem with the language or due to cultural 
> bias is hard to say

Meh, I'd say Haskell has a steeper learning curve, but for experienced
users, "hard to program in" is at best an oversimplification.  Certainly
enough users find it easier than JS that there are some Haskell to JS
compilers to spare people from dealing with JS directly.  JS is
conceptually simple but rather "squishy", and less well suited for
writing complicated programs.

Erlang has less of an entry barrier than Haskell.  It has kind of ugly
surface syntax but it appears to be pretty straightforward to learn,
based on books and code I've looked at.  I haven't actually used it yet
though.

> -- but surely the latter has to both be addressed by the language? I
> don't think it has to do with "nerdiness" (by which you mean cognitive
> distance from C/Algol languages?). 

Haskell in particular requires getting comfortable with more
abstractions than most other langauges require.  By "nerdy", though, I
just mean Haskell and Erlang are minority languages whose programmers
tended to get interested in them because they like trying new things.

> Languages like Clojure seem to be popular -- much more so -- compared
> to Haskell.

I don't have much faith in the Tiobe index but Haskell is above
Clojure in it:

  http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

> http://damienkatz.net/2008/03/what_sucks_abou.html

I've seen that and it is mostly pretty superficial IMHO.

> I'm *not* advocating the Node.JS style of doing things -- just that:
> 1) There is a real "felt need" for highly concurrent non-blocking I/O. 

I'm not convinced of that.  I think there is a need for fast servers
that can handle a lot of concurrency, and node supplies that.  If
Javascript had lightweight processes then using them would have been
preferable to the async approach in my opinion.  However, that's a
matter of preference and there are certainly advocates on both sides.

> 2) That the Node.js approach is the simplest I've seen to date. I've used 
> the new IO in Java, and it is hard to use well. Nowhere near the 
> simplicity of node.js. If there is a "better way", as you claim, then do 
> share!  

The better way is actual multitasking, except that in Java (threads)
it's very expensive, and Javascript doesn't have it at any price, so
node.js uses a single thread, because it has to.  GHC, Erlang, and Forth
(and the newcomers Rust and Go) have cheap multitasking to make
concurrency simpler.

> 3) I believe that Forth could greatly simplify the style of programming 
> that node.js takes (using callbacks, etc), if only superficially due to 
> syntax.  

I can't speak for others but I don't find that prospect attractive.  I'd
rather use multitasking if it's available.  Of course it's still async
and event dispatching under the covers, but I'd rather avoid the control
inversion of the async approach and let the language/runtime keep the
connections separate for me instead of making me do it myself.

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

#14464

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

You would need to add an event handler system and not use the main loop once it's set up.
So all processing happens in event handlers.
I wrote something like this for an Forth based embedded system a long time ago. The event handler is basically "when this event happens, take this action." The event handler system is run on interrupts, or on something like a modern operating system, would be run off the application's message queue. This way the process and by extension the processor can 'sleep' when nothing is going on.

I skimmed java's node.js documentation and it looks like they only allow one event handler run at a time and it runs to completion.  This is probably how they get around the multiple event handlers accessing the same data problem. In order to avoid event 'collision' the node.js event handler system probably has an event queue.

The timeout example shown earlier would work fine for static data but could have problems if your timeout function was doing something like displaying the current value of a variable for the user, such as a voltage meter reading at timed intervals, because the thing changing the voltage meter value could be in the middle of changing it when the timer kicks off. This is unless the updating routine can guarantee the variable update is updated in one uninterrupted step.

This gets me wondering how something like GLUT works which uses callbacks. The callback routine is running in another thread and could interrupt your main program at any time, so how do you avoid data collision problems?

Neither of these two systems can handle event priorities without have data collision problems. Which means that when an event is processing, it blocks all other events from happening. To do it right you'd have to keep your event handlers small and pay attention to how the data is accessed. And you would still probably need another thread or at least state machines for big stuff like drawing a screen.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web