Solution to t=0 being special for Limpets

[GoogleCodeExporter]

Currently Limpets only know about replier bind events that occur subsequent to 
the Limpet being started. This is fine if we assume Limpets being started are 
the first activity on KBus (i.e. before any replier binds), but this is not 
necessarily the case. (The so-called t=0 problem.)

A specific example is a server with many clients repeatedly connecting and 
disconnecting independently, each of which wishes to have a Limpet between it 
and the server. We cannot forbid having any replier binds on the server until 
all the clients are connected (and thus all the Limpets have started) as they 
may never all be connected to the server simultaneously.

One solution would be to have kbus_ksock_report_replier_binds additionally 
inserted a ReplierBindEvent message for every bound replier at the front of the 
calling ksock's message queue, possibly using priority messages. I don't think 
the order in which the messages are inserted would matter.

This solution is neat because it doesn't require any changes to the way Limpets 
work, and if somebody is interested in future replier bind events then they are 
probably also interested in ones that have already happened. The ioctl name 
"KBUS_IOC_REPORTREPLIERBINDS" could probably be left as it is.

Original issue reported on code.google.com by h...@kynesim.co.uk on 23 Jul 2010 at 1:12

[GoogleCodeExporter]

Original comment by t...@tibsnjoan.co.uk on 28 Jul 2010 at 3:57

• Changed state: Started

[GoogleCodeExporter]

Tentative fix in revision 409.

Original comment by t...@tibsnjoan.co.uk on 2 Aug 2010 at 3:01

[GoogleCodeExporter]

The tests in test_kbus.py now need rewriting to test the new behaviour of the 
"start reporting replier bind messages" ioctl.

Original comment by t...@tibsnjoan.co.uk on 2 Aug 2010 at 3:12