On Tue, Aug 24, 2010 at 05:22:39PM +0100, Toby Gray wrote: > > I see a lot of thread support classes... wondering what is the best > > way to handle this code. What do you think of moving it into > > the library? > Yes. I'd be happy to move it into the library if you're happy for some > pthread wrapping code to be in there.
We already have src/scoped_lock.h, and from your example app, it looks like threading may be a useful thing to have when working with modes like raw channel and maybe even the serial / modem stuff. If we can keep these classes simple, header-only classes, then it won't even affect the library much. > The problem with SocketRoutingQueue in it's current form is that if it > gets an error in SocketRoutingQueue::SimpleReadThread() it only outputs > to the error stream; there doesn't seem to be a way (other than > providing some clever ostream as the error stream) to get notified of > these errors currently. I did consider adding an error callback to > SocketRoutingQueue, but then realised that I couldn't do that without > changing the size of the SocketRoutingQueue object and therefore > breaking compatibility with code compiled against the old > SocketRoutingQueue. > > Or do you think it would be ok to modify SocketRoutingQueue to add a > read error callback in a way which would require recompilation by users > of libbarry? Barry is not at version 1.0 yet, so we are not offering ABI guarantees, so a recompile is fine, and API changes are not only allowed, but encouraged if it improves things. As for the issue at hand, after much thought, it seems like the real problem is that SocketRoutingQueue::DoRead() kinda throws away errors. I also think that handshake semaphores should not have to be in the application code either. 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. 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. This would keep protocol details hidden inside the library, where they should be. Thoughts? - 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
