From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A60D1BBC4 for ; Fri, 3 Apr 2009 19:55:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwDANzp1UnRVdq0kGdsb2JhbACVZD8BAQEBCQkMBxEDp2eBCJAlAQMBA4JHAYFEBodeAQ X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="26979785" Received: from mail-bw0-f180.google.com ([209.85.218.180]) by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Apr 2009 19:55:00 +0200 Received: by bwz28 with SMTP id 28so1205558bwz.27 for ; Fri, 03 Apr 2009 10:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RTMR7uUQcCAJ8j9Ag5NLTOIJLSU+8i73ZpPd8WgryCM=; b=xLxh3thC3IoW984eqMD2VMHvh+d2MFluNVRY/iof3RBUENjs/SROFuRf49yVF+agzQ lw+MgAKv6VCi8NSXJiYsH54t7dcbnSdb+AdjNtEwkweBA/AJQaDzAoxbCiRNXIAc4TZE iFtHgZStSUIh+rvTg9+wlyBXXGTn/PQAd5/UE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sSi1OowdSh8R2Nt1FLInQikKjF3GcB0vswFD3o4drEb84H6PJBhXQRhnymFQ+ypIQq 9ESKZWeyZ5TASfW2l2QBwUw5CYmEIKpUL0aHmFp1fPs8E0RegxSxWTD21m/f35GKP37D OCDS6WGwyTT2cgTYkgW73T8CsffgcBJR21qZA= MIME-Version: 1.0 Received: by 10.204.8.84 with SMTP id g20mr487246bkg.167.1238781300197; Fri, 03 Apr 2009 10:55:00 -0700 (PDT) In-Reply-To: <1238773897.9723.6.camel@flake.lan.gerd-stolpmann.de> References: <1238773897.9723.6.camel@flake.lan.gerd-stolpmann.de> Date: Fri, 3 Apr 2009 23:55:00 +0600 Message-ID: Subject: Re: [Caml-list] netplex multi-thread asynchronous processor for passive clients From: Serge Sivkov To: Gerd Stolpmann Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocamlnet-:01 workload:01 multithread:01 workload:01 ssp:98 ideally:01 unix:01 exception:01 caml-list:01 data:02 data:02 define:02 argument:02 output:02 supported:02 Hello, I 've look through sources of the netplex. For now i clearly see how synchronious service works, but i don't understand workflow of anyncronious version of netplex services (i'm using ocamlnet-2.2.9). As says manual, to implement anync version of the processor i must to return control to container right away as first message is sent and don't call when_done. At that moment, container calls #setup_polling, but i don't understand how this code may jumps back to #process? Does services started from one Netplex_main.startup are share same event system for case where their workload_manager sections in configuration file are identical? I've written some code, but it doesn't works :( exception DataArrived (* from #process of the receiver service i call *) container#event_system#add_event (Extra DataArrived) (* and in #process of the sender i doing something like *) let g =3D container#event_system#new_group in container#event_system#add_handler g (fun _ _ evt -> output_string ch "...\n"; flush ch) but no one event has been detected in sender service... Where i'm wrong? >> That code doesn't work because method process called from >> receive_admin_message got wrong fd as argument (i assume, that's >> parent fd used to accept right one). > > No, that does not work. process must be called from the right > environment. > >> What is the right way to write porcessor which must: >> =A0- work asyncroniously with multithread workload manager >> =A0 =A0(ideally, many jobs per thread) >> =A0- work with clients whom don't send any packets >> - get data to send from messages sent by other service > > e.g. open a Unix domain socket, and send data over that socket. Right > now, there is no faster way that is officially supported. For > convenience, you can define RPC procedures that do all the serialization > details. > > What could work if sender and receiver are on the same event system: The > sender puts a special event with the message onto the event queue, and > the receiver installs an event handler listening for such events. I > don't have demo code for something like this, however.