RE: A send-queue type

[Philip Van Hoof <spam pvanhoof be>]

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