From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6CE7E7EE5B for ; Thu, 11 Apr 2013 18:43:56 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.160.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.160.46 as permitted sender) identity=mailfrom; client-ip=209.85.160.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pb0-f46.google.com) identity=helo; client-ip=209.85.160.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-pb0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJXnZlHRVaAuk2dsb2JhbABQiRm7a4EFFg4BAQEBBwsLCRQEJIIfAQEFOgYBGx0BAwwGBQ4KCRUQDwETEQEFARwGCogKAQMPnw2ML4J7hQcKGScNWYh+AQUMjwoHg0EDiQOdLD+ETg X-IPAS-Result: AhYFAJXnZlHRVaAuk2dsb2JhbABQiRm7a4EFFg4BAQEBBwsLCRQEJIIfAQEFOgYBGx0BAwwGBQ4KCRUQDwETEQEFARwGCogKAQMPnw2ML4J7hQcKGScNWYh+AQUMjwoHg0EDiQOdLD+ETg X-IronPort-AV: E=Sophos;i="4.87,456,1363129200"; d="scan'208";a="12874351" Received: from mail-pb0-f46.google.com ([209.85.160.46]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Apr 2013 18:43:55 +0200 Received: by mail-pb0-f46.google.com with SMTP id rp8so943526pbb.5 for ; Thu, 11 Apr 2013 09:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=HMbUlWmT544LPLqYvEUb2IQbwStGXfvyJRCIxSjR2mw=; b=kR6O5Q2NqcFtTUUd3I60DAeSsseU/duCGRRMTwJGiasYGGf3v6lMm5RSTw26zbp/oK +VJp7KeWRggoYfnVAL1qjYHhLZG0t89Oymnv3EXV8lMwWLd7aaWclx7vE8oQds9SbDyV ZzFe+orIIUIdeMKEloLlwb6IUvJAs6fGSjXMtLFWr+jNnXeFl/cmpKvFNjsezP1bopKo cQo6PMIhEjy8X1gi7+LiPJHUIY4RRT4b3WuFwCBpQfN4ZSWJFYSBbmqseatUmhYZDXyo aLIN4N/3+hOuO4EqANwErIPuydzPGAqQ1j7cIMAJR5dM86kM+ZybOmOzAXKhpEmd92bK CKpw== X-Received: by 10.68.35.37 with SMTP id e5mr9700441pbj.208.1365698633986; Thu, 11 Apr 2013 09:43:53 -0700 (PDT) Received: from groupon.localnet (adsl-76-254-28-19.dsl.pltn13.sbcglobal.net. [76.254.28.19]) by mx.google.com with ESMTPS id mt13sm4859847pbc.15.2013.04.11.09.43.51 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 09:43:52 -0700 (PDT) From: Chet Murthy To: Malcolm Matalka Cc: Caml List Date: Thu, 11 Apr 2013 09:43:42 -0700 Message-ID: <2418490.GrNHbtuqlg@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <87fvyxcv1i.fsf@li195-236.members.linode.com> References: <4989654.hHte10Um7f@groupon> <1725573.oORHJHkDHi@groupon> <87fvyxcv1i.fsf@li195-236.members.linode.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml I'm going to answer your question, but I would note that this is sort of immaterial. There -will- be code that wants to use native threads (e.g., -all- odbc code) and when you need to work with that, and do high-concurrency things, you'll either need to come up with a complex method of transferring work between your simulated threads (== monadic threads) and your native threads, or you'll need to work with native threads. In commercial code, native threading is and has been the rule for many years. And if you're going to work with commercial code, you can't afford to rewrite the world. OK, now to your question: In most RPC-compilers, the stubs and skeletons are written on the assumption that on the client the calling thread will block until the response is received. Absent call/cc, there's no real way to change that without changing the generated code. --chet-- P.S. I'm not saying it's impossible. I've hacked Thrift-generated client code to make it usable in an "asynchronous" manner. I just don't have the time to go hacking the idl-compiler right now. On Thursday, April 11, 2013 04:48:25 AM Malcolm Matalka wrote: > Out of curiosity, in what way does Thrift impose threads? Is it > actually handling socket-layer stuff?