in reply to Event-based app and fork()

Yes, “it makes sense to use both fork and poll,” but I'm not sure that I would do it quite in the way you seem to be contemplating.

Let the main thread (so to speak) do the polling, and let it do all of it. Then, when a piece of work has arrived in that way, it can queue it up and let it be processed by one of the "forks" .. the threads .. which sit around waiting for something to arrive in one of the queues they are listening to. The threads don't “poll.”

Notice also that I'm suggesting that the threads don't die off. They stick around, even if at the moment they have nothing to do.

The main-thread is the switchboard operator. Who is, of course, also the boss.

Replies are listed 'Best First'.
Re^2: Event-based app and fork()
by BrowserUk (Patriarch) on Dec 04, 2007 at 13:59 UTC
    Let the main thread (so to speak) ... let it be processed by one of the "forks" .. the threads .... The threads don't “poll.”

    So which are you suggesting to use? Forking or threads?

    Because whilst the OPs question seems very clear to me:"Let's take event loop and fork."; I find your reply very unclear.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I'm using "forking" and "threads," for my purposes, interchangeably. They're not, but.

      The concept that I'm expressing is like you see in any burger-joint. A few people are sitting there in the front waiting for “connections,” which they immediately punch-into the order system. All the rest of the workers are waiting for requests to pop-up on their queues, and when they do, the workers respond. (Your order has been split and sent to everyone's screen at the same time depending on what you order... if the computer is actually working. :-) When the order is finished, the person who took the order hands your burger to you.

      So you have:   one thread that's handling the select-polling; and one or more threads which the work and have nothing to do with polling at all.

        So you have: one thread that's handling the select-polling; and one or more threads which the work

        Yes, but you're completely missing the point of the OPs question.

        You set up you event loop in the primary process (main thread as you incorrectly term it), and then, to start your secondary, long-running, blocking processes, you use fork.

        But, and here the rub, when you fork, you replicate everything that you had in the primary process...

        Now re-read the OPs question starting from "But let's check this in deep..." and see how your reply, plus the conflation of the terms 'forking' and 'threading' mean that you did not even begin to answer the question asked.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        A reply falls below the community's threshold of quality. You may see it by logging in.