Ah so the key is to have the connections in a list, I should have understood that.
Thanks for the help, I'll try it out! On Sun, Apr 25, 2010 at 4:51 PM, Alexander Burger <a...@software-lab.de>wrote: > On Sun, Apr 25, 2010 at 03:17:55PM +0200, Henrik Sarvell wrote: > > So I gather the *Ext mapping is absolutely necessary regardless of > whether > > remote or ext is used. > > Yes. > > Only in case you do not intend to communicate whole objects between the > remote and local application, but only scalar data like strings, > numbers, or lists of those. I would say this would be quite a > limitation. You need to communicate whole objects, at least because you > want to compare them locally to find the biggest (see below). > > > > I took at the *Ext section again, could I use this maybe: > > > > (setq *Ext # Define extension functions > > ... > > (off Sock) ) ) ) ) ) ) ) ) > > '(localhost localhost) > > '(4041 4042) > > (40 80) ) ) > > Yes, that's good. The example in the docu was not sufficient, as it has > a single port hard-coded. > > > > And then with *ext* I need to create that single look ahead queue in the > > local code you talked about earlier, but how? > > The look ahead queue of a single object per connection consisted simply of > a list, the first result sent from each remote host. > > What I did was: > > 1. Starting a new query, a list of connections to all remote hosts is > opened: > > (extract > '((Agent) > (query> Agent <arguments>) ) > (list of agents) ) > > This returns a list of all agent objects who succeeded to connect. I > used that list to initialize a Pilog query. > > 2. Then you fetch the first answer from each connection. I used a method > 'rd1>' in the agent class for that: > > (extract 'rd1> (list of open agents)) > > 'extract' is used here, as it behaves like 'mapcar' but filters all > NIL items out of the result. A NIL item will be returned in the frst > 'extract' if the connection cannot be openend, and in the second one > if that remote host has no results to send. > > So now you have a list of results, the first (highest, biggest, > newest?) object from each remote host. > > 3. Now the main query loop starts. Each time a new result is requested, > e.g. from the GUI, you just need to find the object with the highest, > biggest, newest attribute in that list. You take it from the list > (e.g. with 'prog1'), and immediately fill the slot in the list by > calling 'rd1>' for that host again. > > If that 'rd1>' returns NIL, it means this remote hosts has no more > results, so you delete it from the list of open agents. If it returns > non-NIL, you store the read value into the slot. > > In that way, the list of received items constitutes a kind of look-ahead > structure, always containing the items which might be returned next to > the caller. > > > > I mean at the moment the problem is that I get too many articles in my > local > > code since all the remotes send all their articles at once, thus swamping > > There cannot be any swamping. All remote processes will send their > results, yes, but only until the TCP queue fills up, or until they have > no more results. The local process doesn't see anything of that, it just > fetches the next result with 'rd1>' whenever it needs one. > > You don't have to worry at all whether the GUI calls for the next result > 50 times, or 10000 times. Each time simply the next result is returned. > This works well, and produces not more load than is necessary. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe >
