One final question, how did you define the rd1> mechanism? Simply doing:
(dm rd1> (Sock) (in Sock (rd))) will read the whole result, not just the first result, won't it? I'm a little bit confused since it says in the reference that rd will "read the first item from the current input channel" but when I look at my current usage of rd I get the feeling it will read the whole result? Maybe something is needed on the remote? At the moment there is simply a collect and sort by there. I hope I'm not too cryptic. /Henrik On Sun, Apr 25, 2010 at 5:08 PM, Henrik Sarvell <hsarv...@gmail.com> wrote: > Ah so the key is to have the connections in a list, I should have underst= ood > 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 =A0# Define extension functions >> > ... >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (off Sock)= ) ) ) ) ) ) ) ) >> > =A0 =A0 =A0 '(localhost localhost) >> > =A0 =A0 =A0 '(4041 4042) >> > =A0 =A0 =A0 (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 t= he >> > 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 >> =A0 opened: >> >> =A0 =A0 =A0(extract >> =A0 =A0 =A0 =A0 '((Agent) >> =A0 =A0 =A0 =A0 =A0 =A0(query> Agent <arguments>) ) >> =A0 =A0 =A0 =A0 (list of agents) ) >> >> =A0 This returns a list of all agent objects who succeeded to connect. I >> =A0 used that list to initialize a Pilog query. >> >> 2. Then you fetch the first answer from each connection. I used a method >> =A0 'rd1>' in the agent class for that: >> >> =A0 =A0 =A0(extract 'rd1> (list of open agents)) >> >> =A0 'extract' is used here, as it behaves like 'mapcar' but filters all >> =A0 NIL items out of the result. A NIL item will be returned in the frst >> =A0 'extract' if the connection cannot be openend, and in the second one >> =A0 if that remote host has no results to send. >> >> =A0 So now you have a list of results, the first (highest, biggest, >> =A0 newest?) object from each remote host. >> >> 3. Now the main query loop starts. Each time a new result is requested, >> =A0 e.g. from the GUI, you just need to find the object with the highest= , >> =A0 biggest, newest attribute in that list. You take it from the list >> =A0 (e.g. with 'prog1'), and immediately fill the slot in the list by >> =A0 calling 'rd1>' for that host again. >> >> =A0 If that 'rd1>' returns NIL, it means this remote hosts has no more >> =A0 results, so you delete it from the list of open agents. If it return= s >> =A0 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=3dunsubscribe > > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
