On Wed, Aug 25, 2010 at 05:57:00PM +0100, Toby Gray wrote:
> 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.
Sounds good to me. I'd focus on the asynchronous first. Synchronous
would just be a convenience wrapper on top of that. If I understand
your plan correctly.
> > 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;
> }
If you are suggesting replacing SocketRoutingQueue::SocketDataHandler
with the above class, then I agree. Just turn the SocketDataHandler
typedef into a base class of its own. Probably outside the router
class is cleaner.
I'm thinking that RegisterInterest() should be changed to take a
tr1::shared_ptr of the new SocketDataHandler base class. That way the
application does not have to worry about the order of freeing the
handler class and UnregisterInterest().
SocketData() can be a pure abstract function, but SocketError() should
have a default handler.
> 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.
Sounds good. Thanks!
- Chris
------------------------------------------------------------------------------
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
