Hi Jorge,<div><br></div><div>Even if so, it won't solve many of the other problems I am trying to solve. On the other hand, do you have a Tarball available for download somewhere? (I checked the Google Code page, but no downloads, only SVN access it looks like).</div>
<div><br></div><div> Thank you,</div><div> Noah Silva<br><br><div class="gmail_quote">2012/11/1 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">i reiterate that my Pascal-Actor-Model can do exactly what you are saying...<br>
<br>
writing a "save file in background" type of actor is trivial, and the<br>
synchronization is already done...<br>
<br>
2012/10/31 Noah Silva <<a href="mailto:shiruba@galapagossoftware.com">shiruba@galapagossoftware.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Aldo,<br>
><br>
> Well it's not just synch problems with threads, I've found threads to not be<br>
> so reliable under FPC for anything but trivial test cases. Sometimes the<br>
> program is incredibly slowed when using threads. Also, Unix and Windows<br>
> have to be treated differently, etc. - which is not entirely FPC's fault.<br>
> Making separate applications gives a number of advantages (which I listed in<br>
> my last mail). The need to send data structures back and forth is the only<br>
> 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.<br>
> I wish there was a way to just say something like<br>
> "RunInBackground(procedure)" in FPC. Background threads not being able to<br>
> touch the GUI, etc. makes it all but useless for many purposes. Of course<br>
> for scientific computing type applications where problems can be partitioned<br>
> neatly, threads make perfect sense and work relatively well. For things<br>
> like "I want to save this file in the background while the user continues to<br>
> use the word processor", I've found they aren't anywhere near worth the<br>
> trouble to implement in FPC - yet.<br>
><br>
> For example, if I want only one instance of a daemon running, then I have to<br>
> make it a separate process (reasonably anyway). If I want it to be 64bit,<br>
> but the GUI has to be 32bit, then it has to be a separate process, etc.<br>
><br>
> I will take a look at your framework, because I am interested in all sorts<br>
> of new developments, but it's unlikely I will re-code everything to use a<br>
> particular design pattern or framework.<br>
><br>
> The original question I meant to ask was basically "Is there an easy/mostly<br>
> automatic way to transport data structures between processes", and from all<br>
> the discussion on this list - the answer seems to be "no." Encoding is one<br>
> piece, data transfer is one piece, and the glue in-between (Class factories,<br>
> etc.) is something one probably has to put together themselves. Either way,<br>
> it makes everything more complicated to do something that is in principle<br>
> relatively simple.<br>
><br>
> Thank you,<br>
> Noah Silva<br>
><br>
> 2012/10/31 Jorge Aldo G. de F. Junior <<a href="mailto:jagfj80@gmail.com">jagfj80@gmail.com</a>><br>
>><br>
>> 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>
>><br>
>> _______________________________________________<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>
><br>
><br>
><br>
> _______________________________________________<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>
_______________________________________________<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>