I don't have much to add: really Enjoyed your response.
Thank you for the Validation of the Windows TThread weirdness - nice to
know I wasn't the only one noticing some different behaviour tThread in
Windows versus Linux.
Jason
-----------------
Generally speaking, I've been impressed at how often platform
differences simply are "flawless" in that they seem to usually work
pretty much identical across OS
the ones "i Understood well" and kept adding more to my repetoire - now
I pretty much love the FPC threading model. I'm not a thread hound
either as my hint at multiplexors may suggest but it's pretty slick,
and
gets the job done "Git-r-dun" (B^)>
Well, it's basic, but it works. (I don't like having to add the thread
manager units only on Unix, but...)
You can work them a few different ways and I'm not a threading king but
...
can do this more atomically with call right in thread to pause, or
whatever.
There is a demo that comes with FPC that has two simple processes
writing 1 and 2 to the screen. Believe it or not - I used that simple
demo as the start of my FPC threads education/experimentation.
As did I, but they need a more complicated demo, because most times, the
threads process something for the main program, which means that
requests might build up for the threads, so there needs to be some kind
of queue used (and access to that needs to be safe). There are various
ways to do this, but there should be a demo of at least one so that
people new to this can figure it out. Otherwise, people will hit on the
naive solution of using global variables with a mutex, and discover
strange results when things end up in the wrong place after multiple
requests.
(To make this Synapse relevant, say you make an HTTPDownload thread to
handle downloads in the background. But since it's not running in the
background, the user could initiate another download. Then the results
come in, they have to be matched with the requests - or maybe the
previous request should be canceled when the new one is made?)
I DO need
to point out that in Linux, my interthread messaging system (like your
IPC) works awesome but in windows I had to pick a different algorythm
(less "slick" - and it worked - no exact reason other than I thnk in
windows I get deadlocks maybe and not in Linux or Mac.) Instead of even
I have heard of using the message queue in windows to have the
application "send itself a message" for this purpose. I suppose you
could use IPC from your program to itself too ;) I just use a dynamic
array as a queue for simple stuff. (one for input one for output).
driven "Thread done, pose for next go" In windows I made a queue of
"finished" threads and worked it more like a fifo. (think web server
with 20 idle threads for example waiting for work).
It would be nice to emulate Apple's "blocks" (Grand Central Dispatch)
functionality here. It could use the real implementation on OS X and
BSD, and emulate it with normal threads on other platforms. This would
require some special compiler support to do it the best way though.
In short - I do think it's slick enough for that AND I've had some
success using the FPC "gui-less" stuff perfectly when dropping it into
Lazarus projects (which one hopes for but when I see it work - I cheer)
But of course, I normally write all my stuff in units without any
references to GUI units, and test it with command line programs, then
nothing really depends on the GUI. (Also, even within GUI code, I
usually make a data module and an AppActions inside that, so that all
the code goes there, it makes it much easier to re-arrange forms later,
etc., without having to copy-paste code.)
Where FPC is cheetah, Laz is the finicky cat: awesome when the final
exe
is compiled and purring away but I digress again.
Nonetheless, I have seen Lazarus go from unusable when I first looked
at it to pretty good recently - especially on Mac OS X. Certainly it's
better than Kylix for most uses ;)
Thank you,
Noah Silva
Jason P Sage - Jegas, LLC - 860-871-6691 - 9 West Road FL#1 -
Ellington CT, 06029
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
-------- Original Message --------
Subject: Re: [Synalist] TIMAPSend - solutions for freezing
From: Krzysztof <dib...@wp.pl>
Date: Thu, May 12, 2011 3:59 pm
To: Ararat Synapse <synalist-public@lists.sourceforge.net>
Do you mean that FPC threads can works in background and keep imap
client connected to server? I always thought that they do what they
have
to do and end their action. How this works? Some kind of loop in
Execute
method which keep imap connection and listen for task from main thread?
------------------------------------------------------------------------------
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
