in reply to Re^10: Passing globs between threads (Updated).
in thread Passing globs between threads

I'm thinking you are hypocritcal.

Shame. I was continuing to enjoy this thread.

FWIW: I took you seriously enough to look at trying to implement this is Perl. So far, the information you have provided, or perhaps it's just the information I have succeeded in extracting from your posts (ie. My limitations), mean that I still cannot see how to do it effectively. Complexity is not an issue, I just don't see how to do large parts of this.

Update: My promised update re:Fiber*s. Implementing Co-Routines using Fibers.

* Thanks to bmann

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
  • Comment on Re^11: Passing globs between threads (Updated).

Replies are listed 'Best First'.
Re^12: Passing globs between threads (Updated).
by Anonymous Monk on Oct 09, 2004 at 07:08 UTC
    Did I have used a word that I shouldn't (native german speaker(and no sleep to boot))?

    FWIW: I'm serious. For instance: The distributed transaction idea is from a filesystem that I hope to implement someday. I believe it would be safe as logged and faster than cached. The RFC677 should someday replace DNS. No central point of failure that way. Security is a bitch though.

[reply]
      Did I have used a word that I shouldn't...

      You decide? 

      Heuchler -- eine Person, die Glauben und Meinungen erklärt, daß er nic
+ht hält

      [download]
      FWIW: I'm serious. For instance: The distributed transaction idea is from a filesystem that I hope to implement someday. I believe it would be safe as logged and faster than cached. The RFC677 should someday replace DNS. No central point of failure that way. Security is a bitch though.

      I agree that the mechanism is probably ideal for databases where the vast majority of accesses are readonly references such as DNS and to a lesser extent filesystems. With these, there are relatively few modifying updates, compared to readonly references and/or overwrites with new (unrelated) values. Modifications have to be authorised, which reduces the overall impact of the locking by combining it with the authorisation mechanism. There is also an inherent performance hit related to network communications or diskIO that means that high performance (in the clock cycles sense) is not a criteria.

      I am dubious about it's applicability in the areana of shared variable accesses where (typically) 1/3rd or 1/2 of all accesses are modifications to the current value, accessability is authorisation to modify, and high performance is critical.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
        I could not detect any consistent "Überzeugung". Only with respect to our topic I mean.

        Did you have read my other Node (titled only (Update))? There I'm explaining, that there is no locking involved. The thread must only have the ability to work in the order of its input-queue.

[reply]

In Section Seekers of Perl Wisdom