[Barrelfish-users] IDC confusion
andrewb at inf.ethz.ch
Thu Sep 22 01:22:39 CEST 2011
You're right, we don't have any good support for this at the moment. The current name service implements a very simple mapping from strings to IREFs, and nothing more. If you wanted to use that, you would have to come up with an encoding, such as, for example, encoding the core ID in the name, and registering the same IREF for every client core that should use the same server core. I'll be the first to admit that this is pretty awful.
The longer term plan as I understand it is to use the SKB as a name service. Here you have a complete Prolog interpreter, so you can really implement arbitrary interesting policies about mapping names and client cores to irefs, you just have to figure out how to express those policies in CLP queries :) Unfortunately I'm not aware of any code that does this, so you're a bit on your own if you decide to take that path, but there is nothing stopping you from doing it today. Rather than registering with the name service, you could just record the IREFs of the services as facts in the SKB, and then query them out from the clients. The one thing that you'll miss (from the name service) is the ability to do a blocking query that sends the reply only when the service has registered. If you can't guarantee that the service will start up and register itself before the clients go looking for it, you might want to use the existing name service as a rendezvous/barrier point.
From: Georgios Varisteas [mailto:yorgos at kth.se]
Sent: Wednesday, 21 September, 2011 0:17
To: barrelfish-users at lists.inf.ethz.ch
Subject: [Barrelfish-users] IDC confusion
I've been trying to figure out the IDC and its API but I think that my goal is a bit too complicated for the existing documentation. What I would like to create is a distributed service, meaning a service consisting of multiple cooperating instances running on various (but not all) cores. Each instance is supposed to handle a specific subset of cores. The client-threads are to communicate strictly with the service instance handling their core.
So, I get to the nameservice part and in the absence of any documentation I'm a bit lost. My only idea is to export one service per core and have each client search for the service name of its own core. This is too ugly to even consider implementing so are there any other hints?
Barrelfish-users mailing list
Barrelfish-users at lists.inf.ethz.ch
More information about the Barrelfish-users