From: Patrick B. <pb...@cs...> - 2008-09-20 13:33:21
|
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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |