Hi Aldo,<div><br></div><div>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.<br>
<br>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.<br>
<br>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>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.  </div>
<div><br></div><div>Thank you,</div><div>     Noah Silva</div><div><br><div class="gmail_quote">2012/10/31 Jorge Aldo G. de F. Junior <span dir="ltr"><<a href="mailto:jagfj80@gmail.com" target="_blank">jagfj80@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hm...<br>
<br>
if you gave up using threads because of the problem with<br>
synchronization then you might have a look at my pascal-actor-model<br>
framework...<br>
<br>
its a set of classes that implements Hewitt's Actor Model Concurrency<br>
and its able to solve exactly that...<br>
<br>
<a href="http://code.google.com/p/pascal-actor-model/" target="_blank">http://code.google.com/p/pascal-actor-model/</a><br>
<br>
Code can run assynchronously or synchronously, depending on your needs.<br>
<br>
theres a mainthreadqueue that lets actors talk to the main thread<br>
(where the GUI elements usually reside) using blocking (with timeout)<br>
protocol.<br>
<br>
All messages are actors and can be streamed across the network, etc..<br>
(i am in the process of implementing distributed computing based on<br>
that actor model) etc...<br>
<br>
there are already a lot of components and the basic actor<br>
functionality is already working.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-pascal</a><br>
</div></div></blockquote></div><br></div>