I concur with Krzysztof, especially Krzysztof's Number 4: put it in
another *process* approach.
I have done similar architecture (You're Number 4: put it in another
*process* - Krzysztof) (both in same tree - shared mem implied) or
separate executables using IPC however is fastest - Memory(fast),
TCP(med), File(slowest) - (surprisingly fast with block transfers )
architecture and had great results:
1:Free Parallel processing on multi core systems (as in not too much
effort), no significant impact on single core processors either; as far
as I know.
2:Generally, one can write code to "ask" the thread to shut down, pause
it, resume it, or terminate if it goes rouge or you just want it to
stop. If it's external, IPC can do the same thing but if there is a
communication breakdown, perhaps another means could be devised to reach
out and just terminate the other executable if for some reason IPC was
not responding back with "success" messages.
(In Linux one can kill a process with the "ps" command if they have the
permissions to indeed kill the desired process. In windows I believe you
can accomplish pretty much the same thing with various Windows API's
(32bit/64bit).Net/Os/C++/Old MFC whatever) Therefore it easy to
manipulate a separate process without losing control. Worth the extra
effort? Depends on the project I suppose that's best kept for programmer
to decide themselves: all things considered etc. For software that I'm
serious about... I too will go the extra mile like Krzysztof if I really
need the software to be pretty resilient and fast.
FPC comes with tThread example programs. A quick read on threading, what
is safe to do , not so safe.. and something some folks would think crazy
- called Thread Lucky.
Also - the real bright ones might write a multiplexer that totally
outperforms the separate process method (harder to do - but done well it
can be hands down faster - a bit more than I'm willing to spend a
Saturday on these days)
--Jason - (B^)>
-------- Original Message --------
Subject: Re: [Synalist] TIMAPSend - solutions for freezing
From: Krzysztof <dib...@wp.pl>
Date: Thu, May 12, 2011 4:55 am
To: Ararat Synapse <synalist-public@lists.sourceforge.net>
Trick with another process sounds good. Thanks :)
2011/5/12 Noah Silva <shir...@galapagossoftware.com>
Hi Krzysztof,
I can think of several solutions:
1. Don't call application.processmessages, but something else which only
updates the GUI display (I have seen this mentioned somewhere, but I
don't remember the name of the call now).
2. If you want to allow more than GUI updating, but want to prevent,
f.e. closing the window, then you can track the status of the IMAP
thread, and disallow certain things based upon that. For example the
OnCloseWindow or similar event can prevent the window close if IMAP is
busy.
3. When you say the IMAP is running "on the control" - is this a GUI
component version of the IMAP? If so, you should put it in a DataModule
instead of on the form to solve this problem.
4. You could take the extreme approach as I sometimes do, and just put
it in another *process* which you launch in the background and
communicate with via the IPC components :) This has the added benefit
of automatic queuing.
Anyway what I have wanted to see, and still haven't, is a simple example
for setting/using the OnHeartBeat option from (non GUI) THTTPSend in
code. (Yes, I know it's probably trivial, but examples help everyone).
Thank you,
Noah Silva
2011/5/12 Krzysztof <dib...@wp.pl>
Hi,
When I wanted solve problem with THTTPSend freezing, I always use
threads which works perfect. But HTTP is stateless protocol so this was
good solution, but how to solve problem with TIMAPSend which must have
connection with imap server? I know that exists OnHeartBeat callback
event, but I have bad memories with solutions of this kind. In
OnHeartBeat event I call Application.ProcessMessages or
Application.HandleMessages for GUI refreshing. I get some strange errors
sometimes, for example: user try to close control (tabsheet or form)
where imap is running, he click 2 or 3 times but imap is busy and then
my application crash (I supose HeartBeat call ProcessMessages which try
to destroy this same control again). Anyone know some tricks for
HeartBeat?
Regards
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
