Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #10984
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Subject | Re: FastCGI-like stuff and Forth |
| Newsgroups | comp.lang.forth |
| References | (7 earlier) <7x4nsywth7.fsf@ruckus.brouhaha.com> <27mdnRPKur5HzODSnZ2dnUVZ_sadnZ2d@supernews.com> <7xlima5b3t.fsf@ruckus.brouhaha.com> <NKydndMnK8lRTuPSnZ2dnUVZ_jidnZ2d@supernews.com> <7xzkaoylqr.fsf@ruckus.brouhaha.com> |
| Message-ID | <98ednWQfcu-JSx3SnZ2dnUVZ_q2dnZ2d@supernews.com> (permalink) |
| Date | 2012-04-07 19:04 -0500 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Yes, think of the megabyte or so of stack space allocated per thread >>> (maybe there is a way to adjust that, but still...). >> >> So what? That megabyte is only allocated in the sense that the >> addresses are reserved. There is no memory actually involved until >> the page is first touched. > > And on big x86 linuxes these days, the page size is 1MB(?). Those are huge pages, and they're only used if your memory request is a multiple of the page size. I rather hope that huge pages aren't used by default for thread stacks, but I guess it's not impossible. > Even with 4k page size, that's still far more mmemory per thread > than the few hundred or so bytes for a Forth task. Hmmm. I doubt very much that it makes sense for tasks to share pages, but maybe. >> Perhaps, but I suspect that each of those millions of threads doesn't >> have an I/O socket of its own. > > What's a socket? It's just an integer (file descriptor) that indexes > some table in the kernel. Yes there are associated kernel data > structures so the total number of open ports is limited, but it's to a > pretty big number. The GHC guys[1] claim to have tested with up to > 300,000 connections, though idle. Sure, I can beleieve that. >> You've still got this nasty problem that you're running two >> schedulers, one in the kernel and one in user space, fighting for >> control. There is an argument for moving part of the scheduler into >> user space to facilitate very lightweight threads, I agree, but >> complexifying the (already pretty complex) system so much frightens >> me. > > I may be missing something but I don't understand this scheduler issue. > > 1) I thought Forth multitasking was basically a coroutine switch, > i.e. it's essentially just a cleaner way to organize the control > structure of a traditional single-threaded event loop. So there's > not really a scheduler fighting against another one. Just an event > loop with a tiny bit more overhead due to the task switch (hopefully > less than 100 cycles, maybe just a dozen or so, compared to 1000's > for OS thread switches). OK, but somehow you're going to have to do load balancing between cores. The kernel can't split a single thread that happens to be running a bunch of tasks, so you have to have some way of moving a task from one thread to another. > 2) Even if there's two schedulers, is that so bad? If it really is the best way to do it, no. Sometimes complexity really is justified. Color me skeptical. Andrew.
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
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