Hi Jorge,
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).
Thank you,
Noah Silva
2012/11/1 Jorge Aldo G. de F. Junior <jagf...@gmail.com>
> 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
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
