Re: [Caml-list] netplex multi-thread asynchronous processor for passive clients

[Serge Sivkov <ssp.mryau@gmail.com>]

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 = 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:
>>  - work asyncroniously with multithread workload manager
>>    (ideally, many jobs per thread)
>>  - 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.