Re: ANNOUNCE: DBMail 2.2.2 released

Matthew T. O'Connor wrote:
> Aaron Stone wrote:
>> The next big project is multithreading the daemons.
Even if that's the
>> only change that is made, I think it will take a
while to get right. Of
>> course I'm open to different ideas, and I'm
researching threading
>> frameworks that we can leverage to reduce our
development time. Anyways,
>> getting into those details we should move onto the
dbmail-dev list.
> 
> 
> May I ask why this is important?  Threads aren't the
end-all-be-all that
> lots people think they are.  I believe a multi-process
system can be
> every bit as fast as a threaded server, and it's a lot
less complicated.

Using threading is not a goal in itself, but a means.

One of the goals for 2.3+ is adding new imap capabilities
like NOTIFY
that require a lot of IPC between running imapd processes.
Using threads
will make that quite straightforward.

Another goal is scaling up the number of concurrent
connected clients
without depleting the database connections. Using connection
pools is a
best practice there, and even though that could be done in
a
multi-process architecture, this is generally done using
threads.

So yes, imo also there's a very solid case for threads in
dbmail. But
like Aaron says, it will take some time to do this right.
Neither I nor
Aaron (afaik) have any experience with threads in C so we'll
have to
learn how to do it as we go along 

-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

It may be worth looking at something like APR (http://apr.apache.org/) 
for dealing with things like threads and shared memory on
disparate 
platforms. No doubt this would bloat dbmail somewhat, but
it's always 
nice to not have to do it all yourself, as we've seen with
gmime.

Paul J Stevens wrote:
> Matthew T. O'Connor wrote:
>> Aaron Stone wrote:
>>> The next big project is multithreading the
daemons. Even if that's the
>>> only change that is made, I think it will take
a while to get right. Of
>>> course I'm open to different ideas, and I'm
researching threading
>>> frameworks that we can leverage to reduce our
development time. Anyways,
>>> getting into those details we should move onto
the dbmail-dev list.
>>
>> May I ask why this is important?  Threads aren't
the end-all-be-all that
>> lots people think they are.  I believe a
multi-process system can be
>> every bit as fast as a threaded server, and it's a
lot less complicated.
> 
> Using threading is not a goal in itself, but a means.
> 
> One of the goals for 2.3+ is adding new imap
capabilities like NOTIFY
> that require a lot of IPC between running imapd
processes. Using threads
> will make that quite straightforward.
> 
> Another goal is scaling up the number of concurrent
connected clients
> without depleting the database connections. Using
connection pools is a
> best practice there, and even though that could be done
in a
> multi-process architecture, this is generally done
using threads.
> 
> So yes, imo also there's a very solid case for threads
in dbmail. But
> like Aaron says, it will take some time to do this
right. Neither I nor
> Aaron (afaik) have any experience with threads in C so
we'll have to
> learn how to do it as we go along 
> 
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Paul J Stevens wrote:
> Using threading is not a goal in itself, but a means.
> 
> One of the goals for 2.3+ is adding new imap
capabilities like NOTIFY
> that require a lot of IPC between running imapd
processes. Using threads
> will make that quite straightforward.

OK, though IPC is possible in a multi-process model, but I
agree, 
communication is probably the one place where a threaded
system is more 
simple than multi-process.

> Another goal is scaling up the number of concurrent
connected clients
> without depleting the database connections. Using
connection pools is a
> best practice there, and even though that could be done
in a
> multi-process architecture, this is generally done
using threads.

I don't see how this makes things better, what it sounds
like you are 
suggesting is that DBMail will become in addition to an IMAP
server, a 
database connection pooling engine.  There are tools out
there that do 
this already.

> So yes, imo also there's a very solid case for threads
in dbmail. But
> like Aaron says, it will take some time to do this
right. Neither I nor
> Aaron (afaik) have any experience with threads in C so
we'll have to
> learn how to do it as we go along 

This sounds scary to me.  Obviously it's not my project and
I'm not the 
one coding, I'm just worried as an admin that depends on
DBMail that we 
are going to open up a large can of worms for dubious gain.

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail