From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 06FB0BDCB for ; Fri, 9 Sep 2005 01:33:59 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j88NXwZT022230 for ; Fri, 9 Sep 2005 01:33:58 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA15065 for ; Fri, 9 Sep 2005 01:33:57 +0200 (MET DST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j88NXuD3022225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2005 01:33:57 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EDVsp-0006qT-EJ for caml-list@inria.fr; Fri, 09 Sep 2005 01:32:43 +0200 Received: from 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk ([80.165.187.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 01:32:43 +0200 Received: from spam by 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 01:32:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Bardur Arantsson Subject: Re: announce: callbacks-0.1 Date: Fri, 09 Sep 2005 01:31:47 +0200 Message-ID: References: <43206744.5090907@univ-savoie.fr> <4320A68E.1060608@xs4all.nl> <4320ABF7.7020009@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050803) X-Accept-Language: en-us, en In-Reply-To: <4320ABF7.7020009@univ-savoie.fr> Sender: news X-Miltered: at concorde with ID 4320CA66.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4320CA64.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 lama:01 univ-savoie:01 raffalli:01 ocaml:01 callbacks:01 ocaml:01 ocaml-values:01 callbacks:01 pointless:01 sdu:01 ...:98 ...:98 simpson:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Christophe Raffalli wrote: > Maas-Maarten Zeeman a écrit : > >> >> Hello, >> >>> link: third item of: >>> >>> http://www.lama.univ-savoie.fr/~raffalli/?page=soft&lang=en >>> >>> comment and idea are welcome ! >>> >> >> Sounds like a nice idea. As the author of ocaml-expat a binding I've >> also worked with c -> ocaml callbacks. >> >> It is not really clear to me what problem you are trying to solve. It >> is not very difficult for somebody writing a Ocaml binding to come up >> with a solution which is easy to call an ocaml function value from c. >> >> What I did was create one fixed c-callback functions which: >> >> receive c-parameters >> transform them to ocaml-values >> lookup the ocaml callback "cb" in a tuple (set earlier from ocaml), > > > This is that step I want to avoid ... not mainly for performance, Now, I'll freely admit that I haven't tested it specifically, but I suspect performance will be worse when using register_global_root () to register callback closures instead of just using a mapping from "int" (or whatever type your callback identifier would be on the C side) to closures "stored" on the OCaml side. There was a post on this list not too long ago which exposed efficiency issues with register_global_root when registering lots and lots of roots. >but > because there are some cases where you do not know which callback you > should call (this was the case for one of the glut callback, I don't > recall which one, and it was a bit tricky for glutTimer). It happens > that in glut, the current window or current menu is properly set before > calling the callback ... but there may be other library, more purely > functional, with no concept of "current window" ... > For any C library using callbacks there will *always* be *some* way to distinguish which event/object caused the callback. The reason is simple: Creating callback functions/closures on the fly is impossible(*) in C, or, in other words the callback function itself can't possibly carry enough information to distinguish callbacks from different events/objects. If there isn't enough information to distinguish what caused the callback, the callback would be pointless. (*) Well, you can generate machine code on the fly, but no sane library will force you to do this. -- Bardur Arantsson - In my weaker moments I almost pity them, but then I remind myself: They want to teach. Bart Simpson, 'The Simpsons'