RE: A send-queue type

[Philip Van Hoof <spam pvanhoof be>]

Also look at my OAsyncQueue at cvs.gnome.org ;-)

You'll get the idea quickly.


On Thu, 2006-11-09 at 15:05 +0100, Philip Van Hoof wrote:
> On Thu, 2006-11-09 at 14:55 +0100, Philip Van Hoof wrote:
> 
> > One TnySendQueue would then have a one-one relation with one
> > TnyTransportAccount
> 
> Also very important is that each send-queue would have its own thread
> dealing with the messages.
> 
> And using this design that is very simple (the class will have a
> thread-start method and we are sure that no other threads are
> interfering with the data being dealt with)
> 
> When one queue needs to process using multiple accounts, or this is
> single threaded (which means that messages queued for one account need
> to wait for messages queued on another account), or it's multithreaded
> and all data (of the queue class) is shared by both threads.
> 
> That's why I wrote: more complex, more locking, more etc etc.
> 
> Avoid locking by design ... is my idea here. Just make it two queue
> instances with both the responsibility to process THEIR messages. And
> give the control of deciding who will be responsible to another type: a
> type which I call the classifier.
> 
> Two instances aren't more complex. It's still only one implementation.
> 30,000 instances aren't more complex. Unless you don't want 30,000 file
> descriptors (for each open socket). But ... realistically we don't have
> to care about such numbers here, right? (few people will configure
> 30,000 send accounts).
> 
> 
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog