Hi Aldo,
Well it's not just synch problems with threads, I've found threads to not
be so reliable under FPC for anything but trivial test cases. Sometimes
the program is incredibly slowed when using threads. Also, Unix and
Windows have to be treated differently, etc. - which is not entirely FPC's
fault. Making separate applications gives a number of advantages (which I
listed in my last mail). The need to send data structures back and forth
is the only real disadvantage - but that's just trading for synchronization
issues.
As an aside, threads are one area where it seems ObjC has a huge advantage.
I wish there was a way to just say something like
"RunInBackground(procedure)" in FPC. Background threads not being able to
touch the GUI, etc. makes it all but useless for many purposes. Of course
for scientific computing type applications where problems can be
partitioned neatly, threads make perfect sense and work relatively well.
For things like "I want to save this file in the background while the user
continues to use the word processor", I've found they aren't anywhere near
worth the trouble to implement in FPC - yet.
For example, if I want only one instance of a daemon running, then I have
to make it a separate process (reasonably anyway). If I want it to be
64bit, but the GUI has to be 32bit, then it has to be a separate process,
etc.
I will take a look at your framework, because I am interested in all sorts
of new developments, but it's unlikely I will re-code everything to use a
particular design pattern or framework.
The original question I meant to ask was basically "Is there an easy/mostly
automatic way to transport data structures between processes", and from all
the discussion on this list - the answer seems to be "no." Encoding is one
piece, data transfer is one piece, and the glue in-between (Class
factories, etc.) is something one probably has to put together themselves.
Either way, it makes everything more complicated to do something that is
in principle relatively simple.
Thank you,
Noah Silva
2012/10/31 Jorge Aldo G. de F. Junior <jagf...@gmail.com>
> Hm...
>
> if you gave up using threads because of the problem with
> synchronization then you might have a look at my pascal-actor-model
> framework...
>
> its a set of classes that implements Hewitt's Actor Model Concurrency
> and its able to solve exactly that...
>
> http://code.google.com/p/pascal-actor-model/
>
> Code can run assynchronously or synchronously, depending on your needs.
>
> theres a mainthreadqueue that lets actors talk to the main thread
> (where the GUI elements usually reside) using blocking (with timeout)
> protocol.
>
> All messages are actors and can be streamed across the network, etc..
> (i am in the process of implementing distributed computing based on
> that actor model) etc...
>
> there are already a lot of components and the basic actor
> functionality is already working.
> _______________________________________________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
