Re: [Playerstage-developers] Sending Messages too Fast 2: The Clients' Revenge

[Toby C. <tco...@pl...>]

Sounds a good plan to me, the only other point is that 'marking' the 
messages for proccessing would be trivial since the code already exists 
for marking them for sending, but the maximum count is more flexible and 
probably faster.

Toby

Geoffrey Biggs wrote:
> I like this idea. It means that the driver will process all the messages 
> waiting at the start of the call to ProcessMessages, but won't make it 
> get stuck processing forever nor be less efficient due to copying bits 
> of the queue around. Making an argument to ProcessMessages makes it more 
> flexible, too. We could make the default value of the argument 0 (for 
> process all waiting at start of the call). If the value is a positive 
> number, process that many messages. If the value is -1, process forever 
> (or until the queue becomes empty?). That would provide great 
> flexibility, and by making a default value for the arg of 0 most drivers 
> wouldn't need to be updated and would behave as they do now.
> 
> Geoff
> 
> Brian Gerkey wrote:
> 
>> How about this: ProcessMessages() gets and saves the current length of 
>> the queue before starting its loop.  Then it only Pop()s up to that 
>> many messages off the queue before returning.  No need to lock or mark 
>> the queue.  Just add a public GetLength() method to MessageQueue and 
>> use it in ProcessMessages().  The change is internal to the messaging 
>> system and so doesn't affect the Driver API.  At most, one call to 
>> ProcessMessages() would process a number of messages equal to the 
>> maximum length of the queue (which the driver can already configure).
>>
>> Connected with this issue, we could add an optional argument to 
>> ProcessMessages():  the maximum number of messages that can be 
>> processed in one call.  This would be useful for a driver that wants a 
>> long queue but also bounded processing times for servicing the queue.
>>
>>     brian.
> 
> 
>