Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!news-out.octanews.net!indigo.octanews.net!auth.brown.octanews.com.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: FastCGI-like stuff and Forth References: <2012Apr3.152855@mips.complang.tuwien.ac.at> <7xsjgky7sr.fsf@ruckus.brouhaha.com> <7x398ky33l.fsf@ruckus.brouhaha.com> Date: Wed, 04 Apr 2012 02:20:23 -0700 Message-ID: <7xvclfdfag.fsf@ruckus.brouhaha.com> Organization: Nightsong/Fort GNOX User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:bfOazRQ5w04SvEZ3fH3QS9mppts= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 20 NNTP-Posting-Date: 04 Apr 2012 04:20:23 CDT X-Complaints-To: abuse@octanews.net Xref: csiph.com comp.lang.forth:10855 Bernd Paysan 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.