Could you be more specific about the problem (e.g. big numbers)? VConnection locking works fine in all cases that I know of. There are some issues with closing and deallocation with threading and the higher layers, but these could be solved in a number of ways. Smart pointers is one (and probably not a bad one) although it isn't a panacea, just a mechanism. Similarly, a circular buffer queue is just a different way of viewing the data structure. Sure, it has some advantages, particularly in exposure to deallocation and locking, but it isn't a silver bullet either. I'd like to understand the core problem.
john On Tue, Dec 6, 2011 at 12:22 PM, Alan M. Carroll < a...@network-geographics.com> wrote: > The problem with all of these is that locking for the VConnections is done > poorly, if at all, and closing a VConnection and de-allocating are > conflated. Changing that is hard, though. > > My current plan is related set of changes > > 1) Use a smart pointer (based on lib/ts/Ptr.h) instead of raw pointers, > separating out do_io_close and free. The former can be done as it is now, > but the latter only when the last pointer is dropped. > > 2) Write a new queue class that uses lib/ts/Vec.h to create an expanding > circular buffer. > > 3) Use (2) to replace the current queue support for read_ready_list and > write_ready_list. The problem this solves is that these currently use > intrusive list pointers and that just won't work with (1). OTOH the > instrusive lists do avoid allocations for elements in the list. The > circular queue of (2) should give us the same level of speed with an > acceptable amount of allocation (should be roughly constant per process, as > eventually the queue will get big enough). > > 4) When pulling an element off the ready lists, lock it. If it can't be > locked, put it on the back of the queue. This should not have a big impact > because AFAICT the only reason the lock will fail is because it's being > closed in another thread in which case rapid processing isn't important. > >
