Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #10855
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: FastCGI-like stuff and Forth |
| References | <2012Apr3.152855@mips.complang.tuwien.ac.at> <7xsjgky7sr.fsf@ruckus.brouhaha.com> <jlfk2d$160$1@online.de> <7x398ky33l.fsf@ruckus.brouhaha.com> <jlfmv1$3gp$1@online.de> |
| Date | 2012-04-04 02:20 -0700 |
| Message-ID | <7xvclfdfag.fsf@ruckus.brouhaha.com> (permalink) |
| Organization | Nightsong/Fort GNOX |
Bernd Paysan <bernd.paysan@gmx.de> writes: > I understand what you mean. However, the reason to have threads for > such kind of applications (serving many connections) is that all your > connection IOs are either blocking, *or* they become expensive - Unix's > api is simply bad on that. The UDP api is better, because there, you > can just have one recvfrom listener, and decide on the sender address > what to do with that packet. I'm not sure what you're getting at. Normally if you have a lot of TCP connections, you have a separate socket for each one, and listen to them all simultaneously with something like epoll. So again, you have a single listener and can examine the sender addresses of incoming packets as they arrive, if that's what you want to do. I still don't see why pthreads helps you, unless you want the parallelism of a multicore cpu, which of course creates all sorts of concurrency hazards in your program that you have to watch out for. Presumably the Forth round robin multitasker doesn't actually visit all the blocked tasks while they're blocked? If that's what you meant, it should be easy to fix, I hope.
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