On 24/08/2010 19:08, Chris Frey wrote:
>
> I also think that handshake semaphores should not have to be in the
> application code either.
Agreed. I've been trying to think if it's possible to provide an API
which allows use of both synchronous and asynchronous receiving. This
would make the raw channel API suitable for full duplex protocols (like
brawchannel currently uses) and for simpler send/receive protocols (like
the usbdemo sample from RIM). I think this should be possible by having
two constructors, one which takes a callback pointer (creating a raw
channel which uses RegisterInterest() internally) and the other taking
no callback and requiring manual calls to an explicit receive method.
> So... what if SocketDataHandler callbacks (the callbacks passed into
> RegisterInterest() calls) also took a Usb::Error pointer. Then DoRead()
> would call the callback on both success and error, and the callback could
> process handshaking as appropriate.
That could work. My only reservation is that a callback which either
means you have data to read or an error seems a little messy. Would
splitting the callback out into an interface class be a bit neater?
Something like the following:
class SocketCallback {
public:
// Called when data is available, like the current
SocketRoutingQueue::SocketDataHandler callback
virtual void SocketData(Data*) = 0;
// Called when an error is received on the socket.
virtual void SocketError(Barry::Error*) = 0;
}
> Then in brawchannel.cc, instead of doing a rawChannel.Send() followed
> by a sem.WaitForSignal(), the wait would happen inside rawChannel.Send(),
> and only if needed. i.e. it would block if the handshaking was not complete
> yet.
Agreed, it would be make it a far nicer API if clients didn't have to
mess about with semaphores. I think it should be possible to do this
while still staying responsive to receiving close packets on socket 0
from the BlackBerry.
I've managed to be busy with various unrelated things today, so haven't
had time to do anything more on Barry other than think about how to
improve the raw channel API. When I next get a chance I'll try to update
the API with some of your suggestions and hopefully end up with
something far simpler.
Regards,
Toby
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
