[fpc-pascal] Best way to transfer data between applications?

Fri Nov 2 01:48:41 CET 2012

I've added a source zip to the downloads section of the
pascal-actor-model google code page.

while it cannot do "runinbackground(procedure)" as you want, i believe
it can be mimmicked using the TCreateInstanceAndConfigActorMessage
message and a functor actor (functor is a kind of object that holds
"functions/methods", its a way to mimmick first class functions in a
non-functional language like pascal because it allows to pass function
references/contexts around as classes).

This message can create an actor and pass config info to it in one go,
with guaranteed message delivery and correct sequence. (This avoids
the unbounded non-determinism problem).

Actors usually sit in background doing work or idling. Theres an idle
procedure that can be overridden and you can write message receiving
methods that are triggered upon specific messages.

Actors wont stop until told to stop.

There are a lot of shortcut procedures in the actors.pas unit that
avoids too much verbosity in the code.

If an actor should stop by his own volition, you simply have to set
Running to false after all needed work is done :

Running = False;

There is a request/reply model of message passing, but it should be
avoided at all costs, because it basically stops the thread until the
receiving thread replies (or the timeout expires), the end result is
an almost sequential execution (Makes no sense usually).

The main thread can wait for messages comming from the actors (with
timeout). Its not an active wait (in the sense of a loop) but a
passive wait done using TEventObject.

Usually the correct point to wait for messages comming from the
background actors is inside the application idle loop, via the idle
timer.

Example :

lMessage := ReceiveMessage(500); // waits 500ms for a message to arrive

To send message to actors :

SendMessage(lMessage);

In your example about saving files in background, you can write a file
writer actor and send the content to him as a message. It will happly
save the data to the file while the main thread is free to do whatever
it should do, in parallel.

I believe i should write documentation but i dont know how to use pasdoc yet :P

2012/11/1 Noah Silva <shiruba at galapagossoftware.com>:
> 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 <jagfj80 at 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 <shiruba at 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 <jagfj80 at 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 at lists.freepascal.org
>> >> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>> >
>> >
>> >
>> > _______________________________________________
>> > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>> _______________________________________________
>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal