Hello, I found these two references useful to understand the Event library: *CML: A higher-order concurrent language* John H. Reppy, In *ACM SGPLAN '91 Conference on Programming Language Design and Implementation*, pages 293-305. ACM Press, 1991. http://portal.acm.org/ft_gateway.cfm?id=113470&type=pdf *Higher-order Concurrency* John H. Reppy, *Computer Science Technical Report 92-1285*, Cornell University, June 1992. http://people.cs.uchicago.edu/~jhr/papers/1992/phd-thesis.html I think there is also a short example on how to use this module in OCaml Oreilly book. Hope this helps, Gregory. On 11/9/05, Jonathan Bryant wrote: > > Ok. Two questions. > > First of all, what is going on in the Event module? I can't exactly get > it to work an I fear I'm missing some important concept. I can't find > any documentation other than the interface. Does anybody know of any > further documeeentation or have a good explanation of exactly what's > going on. > > Second, the Thread module allows for individual thread signal masks, but > no way to signal specific, individual threads. It just has a way to > signal one of them pseudo-randomly. Since the signal masks only work > under Unix, why isn't Thread.kill mapped to pthread_kill() since that > would allow much greater flexibility by allowing individual specific > threads to be signaled? > > --Jonathan > > On Wed, 2005-11-02 at 13:29, David Teller wrote: > > Let me rephrase. I don't want to kill just any thread, I want to send an > > exception to whoever is actually synchronising on a channel. Perhaps any > > exception can be "distantly thrown", or perhaps only one specific kind. > > Something like > > > > let sender c = > > ignore Event.sync (Event.send c 1); > > (**Event.send passes an information, > > while Event.sync may pass control.*) > > ignore Event.sync (Event.send c 2); > > ignore Event.sync (Event.send c 4); > > ignore Event.sync (Event.kill c) > > > > and receiver f c = > > f Event.sync (Event.receive c); > > (**Event.receive receive an information, > > while Event.sync may pass control.*) > > f Event.sync (Event.receive c); > > f Event.sync (Event.receive c); > > f Event.sync (Event.receive c); > > (*Actually, this operation throws > > Event.Closed_channel*) > > f Event.sync (Event.receive c) > > > > in > > let c = Event.new_channel () > > in > > ignore (Thread.create sender c); > > try > > receiver print_int c > > with > > x -> (*...*) > > > > In the case of more than two threads waiting for communication on a > > single channel, I would say that they all should receive the exception > > during their next Event.sync. > > > > I agree that this is quite close to your idea of sending thunk > > functions, but the additional indirection strikes me as odd for > > something which to me looks like a primitive. > > > > Cheers, > > David > > > > Le mercredi 02 novembre 2005 à 19:43 +0100, Alessandro Baretta a écrit : > > > David Teller wrote: > > > > > > > However, in my mind, all these solutions are the channel equivalent > of > > > > manual error-handling -- something akin to a function returning an > ('a > > > > option) instead of an 'a because the result None is reserved for > errors. > > > > I'm still slightly puzzled as to why this distant killing/raising is > not > > > > a core feature of channels. After all, unless I'm mistaken, channels > are > > > > a manner of implementing continuations. I tend to believe I should > be > > > > able to raise an error (a hypothetical Event.raise/Event.kill) > instead > > > > of returning/passing a value (as in Event.send). > > > > > > > > Or did I miss something ? > > > > > > "Channel" is maybe an inappropriate term for this strange object. An > > > Event.channel is more like a single-slot mailbox to pass a message to > > > someone. Any number of Threads (zero upwards) can be waiting for > > > messages on a channel. There is no obligation that there be exactly > one > > > thread to kill on the other side. What would happen is try to send a > > > hard-kill event on a channel where there is nobody on the other side? > > > What if the there is more than one thread? > > > > > > You are trying to find a way around killing a thread with Thread.kill, > > > but there is really no way to cleanly kill a thread asynchronously. A > > > clean exit requires some cooperation from the killed thread. > > > > > > Alex > -- > --Jonathan Bryant > jtbryant@valdosta.edu > Student Intern > Unix System Operations > VSU Information Technology > > "Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil." > ("Life without music is simply an error, a pain, an exile.") > --Frederich Nietzsche > > "The three cardinal values of a programmer are laziness, impatience, and > hubris." > --Perl Man Page > > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >