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

Groups > comp.lang.forth > #10927

Re: FastCGI-like stuff and Forth

Show all headers | View raw

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> that?  One way is multiple Unix processes or pthreads, but these are
>> quite expensive
> More expensive than actually doing the I/O calls, blocking, and so on?

Yes, think of the megabyte or so of stack space allocated per thread
(maybe there is a way to adjust that, but still...).

>> and pthreads introduce the usual locking hazards.
> Aha!  We all need my STM Forth!  ;-)

It could be pretty cool in cases where pthreads are really needed, or
for shared memory between processes.

>> (the client interface looks like a blocking read, but is actually a
>> library call doing an async read
> That doesn't sound like a cleaner design than having each thread
> listening to its own socket.  You agree, surely?  

It's transparent to the client, which thinks it's just doing a blocking
read.  It does hair up the runtime some, but the performance gain seems
to be worth it.  You could think of it as undoing an abstraction
inversion created by sockets.  How would you implement a concurrent web
server if your network interface was directly to the ethernet port,
instead of having OS-supplied TCP/IP?

> Green threads, in other words.  Linux threads are pretty lightweight.

No, they're huge.  You can run millions of GHC or Erlang threads on a
reasonable sized server, but not more than a few thousand Linux threads.

> N:M threading (with N threads on M kernel LWPs) is the way Solaris did
> it (still does?  I don't know)

There is some discussion about N:M in the C10k article and apparently
it was deprecated, at least for a while.  The reason to do it now is
multiple cores.  It works out nicely in Erlang since the threads are
completely isolated from each other, and it's not too bad in Haskell
since one normally writes in a style using very little mutable data.

> I am sure that it's possible to write a benchmark which proves that if
> you have a great many tasks, each doing almost nothing, it's more
> efficient to multiplex all the work onto a single process.  How
> realistic that is with an actual server load is another matter.

I see lots of sites using Nginx (which uses async i/o) instead of Apache
these days, because of Nginx's lower overhead.  Similarly Lighttpd.

> Besides all of this, these days most desktop/server boxes have a bunch
> of cores waiting for something to do, and that is going to become
> increasingly common.

Yeah, with this scheme in Forth, the simplest approach may be to
implement M:N by just running multiple processes with cooperative
multitasking in each one, letting a front end load balancer deal out
requests to the multiple processes.  That gets you some trivial crash
recovery too.  This is done routinely in Python because of the GIL
(Global Interpreter Lock), a notorious Python implementation artifact
that stops multithreaded Python programs from actually gaining
parallelism from multiple cores.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

FastCGI-like stuff and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-03 13:28 +0000
  Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-03 11:44 -0700
    Re: FastCGI-like stuff and Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-03 21:46 +0200
      Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-03 13:25 -0700
        Re: FastCGI-like stuff and Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-03 22:35 +0200
          Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-04 02:20 -0700
            Re: FastCGI-like stuff and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-04 05:52 -0500
              Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-05 00:03 -0700
                Re: FastCGI-like stuff and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-05 03:03 -0500
                Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-05 10:42 -0700
                Re: FastCGI-like stuff and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-06 06:30 -0500
                Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-07 01:44 -0700
                Re: FastCGI-like stuff and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-07 19:04 -0500
                Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-07 17:40 -0700
        Re: FastCGI-like stuff and Forth quiet_lad <gavcomedy@gmail.com> - 2012-04-05 13:37 -0700
    Re: FastCGI-like stuff and Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-04 13:20 +0000
      Re: FastCGI-like stuff and Forth Paul Rubin <no.email@nospam.invalid> - 2012-04-04 11:20 -0700
    Re: FastCGI-like stuff and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-04 13:42 +0000
  Re: FastCGI-like stuff and Forth Spam@ControlQ.com - 2012-04-04 17:00 -0400
  Re: FastCGI-like stuff and Forth quiet_lad <gavcomedy@gmail.com> - 2012-04-05 13:36 -0700
  Re: FastCGI-like stuff and Forth quiet_lad <gavcomedy@gmail.com> - 2012-04-13 23:10 -0700

csiph-web