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
