Re: Drat! (2) (Re: Todo list -- POP3 retriever) (threads/libmutt/rewrite/long subject)
- From: Chris Gonnerman <chris gonnerman usa net>
- To: Peter Williams <peter newton cx>
- Cc: balsa-list gnome org
- Subject: Re: Drat! (2) (Re: Todo list -- POP3 retriever) (threads/libmutt/rewrite/long subject)
- Date: Tue, 23 Nov 1999 09:51:21 -0600
On Mon, 22 Nov 1999, Peter Williams wrote:
>On Mon, 22 Nov 1999 14:13:06 David Pickens wrote:
>> On Mon, 22 Nov 1999, Chris Gonnerman wrote:
>> > The only thing I can think of that would save my code is running calls
>> > to the launch_next_job() code in a separate thread; but that fails at
>> > avoiding threading altogether, which was my goal. Contrary to popular
>> > belief, GNOME does NOT require threading (proved by the system I am on
>> > now, SuSE 5.2/Linux 2.0.35/libc5 with October GNOME on it).
>> > Why try to avoid threading? Because I am not the only poor sucker with a
>> > non-glibc system who doesn't want to screw with it (because it works).
>> This is upsetting in that I'd be the last person to want to produce a mail
>> client that large numbers of people couldn't use. On the other hand,
>> allowing the user to specify the behavior at compile-time might be the
>> best solution.
>Hmmm.... I'm not too comfortable with this idea, but I think it is the best
>option. Accomodating the threadless is okay, and with a few macros we should
>be able to abstract pretty well... but would we want to implement code twice,
>as a thread and as a state machine, or give really long blocks on downloading
>of mail, etc.? State machines seem to be the best approximation of threads
>but implementing the code twice is Bad.
I was talking about running the hostname-lookup and connect() in a second
thread, but then the download would proceed as a gdk_input function in the main
thread... but now I'm not sure how to cleanly transfer control to the main
thread. Assuming that can be solved, the rest of the transfer would be a state
machine; the #ifdef block(s) would be relatively small.
>Speaking of this... I *must* figure out how to make the GUI not lock while
>sending messages.... it is SOO ANNOYING. :-) That's good to hear that the
>threading code is happy.
Sending messages in a thread or via gdk_input_add/state-machine (either one)
should solve the lock on sending messages. Even if you send messages via a
pipe() to sendmail, you can still use an input function (output function?) to
do the work.
] [Thread Prev