in reply to Re^10: OT: Locking and syncing mechanisms available on *nix.
in thread OT: Locking and syncing mechanisms available on *nix.

Hopefully we're on the same page now, though I'm getting well outside my area of personal experience (I've done threaded programming, but avoid it like the plague in Perl). IIUC switching between Perl interpreter contexts is painfully expensive, and since each queue message requires 3 switches (wait/signal/wake), that can crush you.

I haven't used them before, but isn't this a good place to apply Coro and/or Coro::EV? The Coro docs even say:

Benchmarks using i-threads which are communication-intensive show extremely bad behaviour with i-threads (in fact, so bad that Coro, which cannot take direct advantage of multiple CPUs, is often orders of magnitude faster because it shares data using real threads, refer to my talk for details).
  • Comment on Re^11: OT: Locking and syncing mechanisms available on *nix.

Replies are listed 'Best First'.
Re^12: OT: Locking and syncing mechanisms available on *nix.
by BrowserUk (Patriarch) on Mar 27, 2011 at 21:40 UTC
    isn't this a good place to apply Coro

    No. It would completely defeat the purpose of the threading, which is to spread the cpu load of a process across multiple cores. Coro does not (can not) utilise multiple cores or processors.

    The Coro docs even say

    Unfortunately, the Coro docs are little more that a work of unimaginative fiction. They render some very clever code and coding--when used for appropriate purposes--almost valueless due to the asinine headline claim; knowingly, utterly biased and useless benchmark; and a complete misunderstanding or misrepresentation of ithreads.

    For my purpose, they are entirely inappropriate.


    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.