[Barrelfish-users] Question about message passing

[Tim Harris (RESEARCH)]

Hi Zeus,

May be worth taking a look at the work in our upcoming OOPSLA paper:

AC: Composable Asynchronous IO for Native Languages Tim Harris, Martín Abadi,
Rebecca Isaacs, Ross McIlroy, OOPSLA 2011

Note that the source code uses the name "THC" instead of "AC".

There are two parts of THC (#1) the language extensions DO_FINISH/ASYNC/CANCEL, and (#2) a runtime system and a set of blocking operations that are integrated with the runtime system.

It's probably simplest for you just to look at #2 for now: you can stick with the current basic structure of the program, but use blocking send/receive operations within event handlers.

Assuming you're using a reasonably recent tree you'll need to:


·         Link with the thc runtime system (see the "addLibraries" line in the Hakefile in usr/tests/thcidctest).


·         Generate THC stubs for the interfaces (see the "flounderTHCStubs" line in the Hakefile).


·         Include thc/thc.h and the Flounder-generated XXYZ_thc.h files for each interface XXYZ that you use.


·         Use XXYZ_thc_init_client and XXYZ_thc_init_service to initialize THC client/service binding structures for the bindings on which you want to use blocking IO operations.  By default this will install message handlers for every message on the underlying binding.  You should run these init functions first, and then overwrite the default message handlers with your own ones, if you wish.  (See the calls to the bench_thc_init_client/...init_service functions from usr/tests/thcidctest/empty.c)


·         See the client_thc function in usr/tests/thcidctest/empty.c for examples of invoking blocking IO operations.

Note that:


·         The THC runtime system uses the "st" field of the underlying binding structures.


·         For each incoming message you need to decide whether to receive it via blocking THC operations (in which case you leave the message handler installed by the init functions intact), or whether to receive it by writing your own up-call (in which case you just overwrite the default function with your own in the rx_vtbl, as usual).

Let me know how you get on,

Cheers,

Tim

From: Zeus Gómez Marmolejo [mailto:zeus.gomez at bsc.es]
Sent: 05 September 2011 20:20
To: barrelfish-users at lists.inf.ethz.ch
Subject: [Barrelfish-users] Question about message passing

Hi,

I have a question regarding message passing using the UMP backend.

I understand that inside a message handler that has been called via the event_dispatch() you cannot block in case the transmit queue is full. So you cannot call event_dispatch() again, the only way is to register a callback when the message is sent...

So the problem is that I'm a bit stuck, as I cannot return an error to the user. The message has to be sent anyway. And of course, saving the message in a temporary buffer, copying all arguments back to the buffer and using the callback to copy them again for sending is not practical as the performance drops dramatically.

Is there any way that I can solve this?


Many thanks,


--
Zeus Gómez Marmolejo
Barcelona Supercomputing Center
PhD student
http://www.bsc.es

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20110906/ab5c2768/attachment.html