Hi,
2011/5/13 <jasonps...@jegas.com>
> Hi! Those TThreads seem to have the main things I needed. I just used
> 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
