Balsa can't send out 2 unQ messages simultaneously ?

["Timothy Ang" <leonhong2001 yahoo com>]

Hi!
Thanks for your reply.

I noticed that Libmutt can't handle huge files very well,
especially with big mailboxes or attachments and it slows
down the system a lot. Besides Mutt is a "console" program,
which multi-threading may not have been a factor in designing
the program. Balsa, however, is a UI application... and somehow,
the combination of Libmutt and Balsa doesn't really fit in well in
the long run. Well, that's my perception.

One interesting observation on Balsa...
I prepared two compose windows on Balsa, all filled with the
necessary data and attachments of 2mb each. Both windows have
the "Always queue mail" check button turned off. I sent one message
off and while it was still sending through SMTP, I clicked "Send" on the
other window. Balsa hanged. The purpose of this simulation is to show
that if a message is being sent onto SMTP and has not yet finished, Balsa
doesn't seem to handle the second send very well. Seems to me that
there's a deadlock somewhere.

Either way, with a slight modification on the codes, while one message is
still being sent out, the other message when the Send button is clicked,
that message is queued in Outbox automatically. This procedure might
have saved Balsa from hanging, but when sending is over, the message
that was queued automatically could not be sent out immediately.
Wonder if you know a way whereby Balsa can send a signal to
do a "libbalsa_process_queue" on its outbox so that the queued messages
can be sent out immediately?

Help is appreciated.

Best Regards,
Timothy Ang.

----- Original Message -----
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: "Pawel Salek" <pawsa@TheoChem.kth.se>
Cc: "Timothy Ang" <leonhong@singnet.com.sg>; <balsa-list@gnome.org>
Sent: Friday, April 05, 2002 3:44 AM
Subject: Re: LibMutt's Base64 Encoding Speed



Am 04.04.02 14:15:14 schrieb(en) Pawel Salek:
>> I wonder if anyone can offer an alternative or any amendments
>> to Libmutt's Base64 functionalities?
>
> I have noticed it, too. There is a space for optimization at least by
> factor of 2, I think.

A while ago, I tried to investigate this in greater depth (I have a rather
old PowerMac with a 166MHz 604e, so it's a problem which really bites; even
Nutscrape is much faster in en-/decoding than balsa!). It's not only that
the libmutt routines are slow; for one message, the conversion is called
multiple times. If I remember correctly, at least twice (for the message to
be sent plus for the copy in the sentbox). If this is still ture, we could
gain much more that a factor of two (maybe four?) if we introduce some kind
of cache for converted attachments. I have no idea if this breaks MT at some
point, but if it is not too difficult, it would be a great improvement.

> I do not know of any. The attachments are not kept in memory so I guess it
> is the temporary disk space that limits.

Some MTA's have limits on the maximum size for mail reception, typically
several MB's...

Cheers,

Albrecht.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
_________________________________________________________________________



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com