i reiterate that my Pascal-Actor-Model can do exactly what you are saying...
writing a "save file in background" type of actor is trivial, and the synchronization is already done... 2012/10/31 Noah Silva <shir...@galapagossoftware.com>: > 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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
