The replace rules and pull mode were both implemented for the client communications, as such they ahve not been well defined or testing for drivers. When a client sends a request for data the server marks all the messages in its queue ready for transmission and appends a sync message. These ready messages are then written to the clients socket.

For a driver this model is fairly clunky as I believe you would have to manually call the methods to mark messages ready and then call process messages. For drivers you should be able to use replace rules without using pull mode as there is no operating system buffer to hold the messages in (which is what makes replace rules fail for client in push mode).

Does this shed any more light?

Toby

2008/9/21 Patrick Beeson <pbeeson@cs.utexas.edu>
Geoff wrote:
> InQueue->SetPull(true) is changing the driver's message queue to pull mode,
> which means you need to explicitly pull messages of the queue in the
> driver's loop. They won't be pulled off and sent to ProcessMessage()
> automatically.
>
> Geoff

OK.  That's helpful.  Three more quick questions then:

1) This has changed since Player 2.0.  I can run the exact same thing in
Player 2.0 (have a driver in pull mode), and ProcessMessages *does* call
ProcessMessage.  So, have the semantics of Pull (server side) changed or
they were broken before?  Just curious.

2) There is no example of writing a driver that uses pull mode -- just
the comment in messages.h that is better for getting the most up to date
data.  Would a reasonable method be:

Driver::Wait()
while !Inqueue::empty()
       message=Inqueue::Pop()
       ProcessMessage(message)

3) I understand the PUSH/PULL semantics for clients because that
involves when to pass data across TCP.  I don't understand what it does
for drivers---the comment on pull in messages.h says: "Push is default
mode, but pull is the recommended method to avoid getting delays in data
on the client", which doesn't really discuss how this affects drivers.

So is it that for server-side drivers the only difference between
pull/push is that the driver needs to manually pop its queue?  If so,
then there really is no benefit for PULL over PUSH on the server side
(which is what I suspect, but am unsure of)?

Note: The reason why I have drivers that user SetPull is that previous
programmers on my project used Pull with Replace mode in
Drivers---presumably either a) because of old documentation that Push
mode and Replace mode don't play nice for clients (for the obvious TCP
buffer reasons) or b) because it was necessary to fix some
unpleasantness they were seeing in message delivery.  Only in Player 2.0
this line of code seemed benign, while now it actually seriously affects
the way drivers work.

Again, my best guess right now is that using pull server side
essentially just means that the driver has to manually process its own
queue?  and that's all it does?  if so, then I'll make sure to go
through and turn it off everywhere.


Thanks for the help,
Patrick



>
> Patrick Beeson wrote:
>> I just found a weird behavior that I think is a bug or masks a bug in
>> Player 2.1.1.
>>
>> For a plugin or driver, if you call InQueue->SetPull(true) (this is left
>> over from Player 2.0.5 and I'm not sure its necessary anymore), then
>> ProcessMessages() never calls the local ProcessMessage() method on the
>> Driver class.
>>
>> It's very simple to test, build a driver (e.g. the OpaqueDriver from the
>> Player 2.1.1 source), and make a simple client that sends a command to
>> this driver.  Add a print statement in the local ProcessMessage of the
>> driver, no need to actually handle the command sent.
>>
>> Run Player and the client to see the printed statement each time the
>> client sends the command down.
>>
>> Now, Add the SetPull(true) command from above to the Driver's
> constructor.
>> Run it again, and the print statement has no effect because
>> ProcessMessage in the driver is never called.  Add more print statements
>> around ProcessMessages() in the main loop and you'll see that it is
>> still being called.
>>
>> To me SetPull(true) might have some change to the way messages are
>> passed (I never fully understood that this did on the DRIVER side, as it
>> wasn't ever documented satisfactorily -- at least no where that I saw),
>> but it shouldn't cause ProcessMessage() to not be called.
>>
>> Because this is not the default, I'm worried it could be hiding other
>> bugs that may exist in the 2.1 branch, and right now I don't have time
>> to investigate this further.
>>
>>
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers



--
This email is intended for the addressee only and may contain privileged and/or confidential information