1. Interprocess Communication...
I'm trying to use PatRat's IPC.ew library, and I have a few questions
about how it all works...
(Basically, it does some trickery with shared memory, call_backs, and
other low-level stuff)
I have two programs running, A & B. B has registered a function with
the library.
A uses ipc_CallProc() to call the function in B.
In what process does the function within program A run? A or B?
If there is a run-time error within B's function that A called, what happens?
Is there anyway to set some kind of time-out in the inter-program
call, so that if something goes wrong inside the other program (like
an infinite loops, etc) it can still return?
--
MrTrick
2. Re: Interprocess Communication...
- Posted by "Kat" <gertie at visionsix.com>
Nov 10, 2004
-
Last edited Nov 11, 2004
On 10 Nov 2004, at 22:36, Patrick Barnes wrote:
>
> I'm trying to use PatRat's IPC.ew library, and I have a few questions
> about how it all works...
> (Basically, it does some trickery with shared memory, call_backs, and
> other low-level stuff)
We should ban him from the list, tell him to go use a language that provides
threads already, and then burn him at the stake. No one needs ipc, just like
no one needs goto. He allows you to clutter up the machine with those other
threads. It's not inately in Eu, and therefor it's BAD. Hang him! Same with all
those people writing games by using winapi calls! They're DEMONS!
-- demonic code follows --
if offended_by_commentary then goto eoemail end if
Kat,
The primary lobby for ipc way back when, but found Elegant, and reformed
and repented, all praise Elegant! Elegant's priests told me earth was the
center of the universe, and so it is! Elegant runs my life now, i have no free
will!
:eoemail
-- eo = end of
-- so eoemail = end of email
-- how's that for hard to maintain and hard to read?
grrrr
3. Re: Interprocess Communication...
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 10, 2004
-
Last edited Nov 11, 2004
On Wed, 10 Nov 2004 13:01:45 -0600, Kat <gertie at visionsix.com> wrote:
> > I'm trying to use PatRat's IPC.ew library, and I have a few questions
> > about how it all works...
> > (Basically, it does some trickery with shared memory, call_backs, and
> > other low-level stuff)
>
> We should ban him from the list, tell him to go use a language that provides
> threads already, and then burn him at the stake. No one needs ipc, just like
> no one needs goto. He allows you to clutter up the machine with those other
> threads. It's not inately in Eu, and therefor it's BAD. Hang him! Same with
> all
> those people writing games by using winapi calls! They're DEMONS!
Uh, I most sincerely hope you're joking. (Suspected, given the GOTO
discussions earlier)
I'm not using IPC for the purposes of threads! I have a main program
that has expandable 'modules'. Each module is a Euphoria program that
conforms to the module framework (includes the framework library,
contains certain procedures, etc). Similarly to win32lib, the last
statement of the program cedes control to the framework library.
That way, new modules can be added while the main program is still
running, and if a nasty error (as not all modules will be written by
me) occurs, the main program does not crash.
It could be single-threaded, I don't care! My main question is, what
happens if something goes wrong in a module program? I know there are
a few projects that use IPC - MEditor for one...
--
MrTrick
4. Re: Interprocess Communication...
- Posted by "Kat" <gertie at visionsix.com>
Nov 10, 2004
-
Last edited Nov 11, 2004
On 11 Nov 2004, at 7:29, Patrick Barnes wrote:
>
> On Wed, 10 Nov 2004 13:01:45 -0600, Kat <gertie at visionsix.com> wrote:
> > > I'm trying to use PatRat's IPC.ew library, and I have a few questions
> > > about how it all works...
> > > (Basically, it does some trickery with shared memory, call_backs, and
> > > other low-level stuff)
> >
> > We should ban him from the list, tell him to go use a language that provides
> > threads already, and then burn him at the stake. No one needs ipc, just like
> > no one needs goto. He allows you to clutter up the machine with those other
> > threads. It's not inately in Eu, and therefor it's BAD. Hang him! Same with
> > all those people writing games by using winapi calls! They're DEMONS!
>
> Uh, I most sincerely hope you're joking. (Suspected, given the GOTO
> discussions earlier)
I was joking, yeas.
> I'm not using IPC for the purposes of threads! I have a main program
> that has expandable 'modules'. Each module is a Euphoria program that
> conforms to the module framework (includes the framework library,
> contains certain procedures, etc). Similarly to win32lib, the last
> statement of the program cedes control to the framework library.
>
> That way, new modules can be added while the main program is still
> running, and if a nasty error (as not all modules will be written by
> me) occurs, the main program does not crash.
>
> It could be single-threaded, I don't care! My main question is, what
> happens if something goes wrong in a module program? I know there are
> a few projects that use IPC - MEditor for one...
Depening on how you set ipc up, you can have the main process dependant
on the spawned processes or not. It's the best thing since slice bread (no
joking). In the place of threads, and even if we do get threads, the ipc may be
better, since it allows (mandates) separate everything except what the coder
wishes to share.
If you want to use Eu code on separate operating systems in the same way
as ipc, check out the socks code in the archives. I linked mirc and eu on
win95 to a vb app on winxp, and php running on nix once, over the internet,
altho you can do the same on a lan.
Kat
5. Re: Interprocess Communication...
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 10, 2004
-
Last edited Nov 11, 2004
On Wed, 10 Nov 2004 16:06:08 -0600, Kat <gertie at visionsix.com> wrote:
> > I'm not using IPC for the purposes of threads! I have a main program
> > that has expandable 'modules'. Each module is a Euphoria program that
> > conforms to the module framework (includes the framework library,
> > contains certain procedures, etc). Similarly to win32lib, the last
> > statement of the program cedes control to the framework library.
> >
> > That way, new modules can be added while the main program is still
> > running, and if a nasty error (as not all modules will be written by
> > me) occurs, the main program does not crash.
> >
> > It could be single-threaded, I don't care! My main question is, what
> > happens if something goes wrong in a module program? I know there are
> > a few projects that use IPC - MEditor for one...
>
> Depening on how you set ipc up, you can have the main process dependant
> on the spawned processes or not. It's the best thing since slice bread (no
> joking). In the place of threads, and even if we do get threads, the ipc may
> be
> better, since it allows (mandates) separate everything except what the coder
> wishes to share.
Yes, it would be very nice if a form of IPC was integrated with
Euphoria. Apart from the other advantages, we could even make the
Euphoria equivalent of DLLs!
> If you want to use Eu code on separate operating systems in the same way
> as ipc, check out the socks code in the archives. I linked mirc and eu on
> win95 to a vb app on winxp, and php running on nix once, over the internet,
> altho you can do the same on a lan.
No, they are on the same computer. The reason they're separate
programs is because this is in regards to my preparing the second
contest, so I'm gonna be a little secretive about details. (This is
for the framework each competitor will use, not the actual goal of the
contest)
The main thing is - if a program crashes when one of its functions is
called remotely, does it crash the calling program, and can the
calling program detect that the other program crashed?
Looking at the internal code in IPC.ew, it uses the C function
"SendMessageA" to access the function in the other program (identified
using call_back() )
--
MrTrick
6. Re: Interprocess Communication...
- Posted by "Kat" <gertie at visionsix.com>
Nov 10, 2004
-
Last edited Nov 11, 2004
On 11 Nov 2004, at 10:02, Patrick Barnes wrote:
<snip>
> The main thing is - if a program crashes when one of its functions is
> called remotely, does it crash the calling program, and can the
> calling program detect that the other program crashed?
There are ways, i forget how, to detect if any program is running. Also to kill
it. Code is in the archives. Detecting if the module is sitting there with a dos
box and whining that you must press <enter> , i don't know. If you want to
maintain if the spawned modules is running, it should either send a ping or
respond to one periodically. Or be doing something else that can be
detected by the main process externally. For my mirc-eu, i pinged with a
number representing the time, pretty much like irc does anyhow.
Kat
7. Re: Interprocess Communication...
On Wed, 10 Nov 2004 17:49:26 -0600, Kat <gertie at visionsix.com> wrote:
> <snip>
> > The main thing is - if a program crashes when one of its functions is
> > called remotely, does it crash the calling program, and can the
> > calling program detect that the other program crashed?
>
> There are ways, i forget how, to detect if any program is running. Also to
> kill
> it. Code is in the archives. Detecting if the module is sitting there with a
> dos
> box and whining that you must press <enter> , i don't know. If you want to
> maintain if the spawned modules is running, it should either send a ping or
> respond to one periodically. Or be doing something else that can be
> detected by the main process externally. For my mirc-eu, i pinged with a
> number representing the time, pretty much like irc does anyhow.
Yes, it would be nice to be able to close the euphoria error console
that appears when an error occurs.
I'd _rather_ not need some kind of heartbeat function to make sure the
thing still works...
The main process wouldn't really be running - I can't quite tell, but
I think the IPC library is synchronous. That is, once a remote
procedure/function is called, it doesn't return until that procedure
is finished.
Maybe I need to implement a custom communications system.... *grumbles*
--
MrTrick
8. Re: Interprocess Communication...
Patrick Barnes wrote:
>
> On Wed, 10 Nov 2004 17:49:26 -0600, Kat <gertie at visionsix.com> wrote:
> > <snip>
> > > The main thing is - if a program crashes when one of its functions is
> > > called remotely, does it crash the calling program, and can the
> > > calling program detect that the other program crashed?
> >
> > There are ways, i forget how, to detect if any program is running. Also to
> > kill
> > it. Code is in the archives. Detecting if the module is sitting there with a
> > dos
> > box and whining that you must press <enter> , i don't know. If you want to
> > maintain if the spawned modules is running, it should either send a ping or
> > respond to one periodically. Or be doing something else that can be
> > detected by the main process externally. For my mirc-eu, i pinged with a
> > number representing the time, pretty much like irc does anyhow.
>
> Yes, it would be nice to be able to close the euphoria error console
> that appears when an error occurs.
>
> I'd _rather_ not need some kind of heartbeat function to make sure the
> thing still works...
>
> The main process wouldn't really be running - I can't quite tell, but
> I think the IPC library is synchronous. That is, once a remote
> procedure/function is called, it doesn't return until that procedure
> is finished.
>
> Maybe I need to implement a custom communications system.... *grumbles*
>
I have a system worked out to do what you want (I think). However, the details
of how I did it escape me at the moment -- I have to dig up the code. It is too
much to post -- email me and I'll send you an example.
9. Re: Interprocess Communication...
i have a generic include module that i actually named 'pulse' to keep
track of other running programs. it uses shared memory instead of IPC.
i can send it to privately if you'd like. i need to clean it up before
submitting it to the archives. i didn't think anybody else would need
it besides me.
Yours, OtterDad
Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
10. Re: Interprocess Communication...
Now that sounds good.
I've also been playing with a 'modular' framework, it works, but is not too
elegant for my liking, I'd love to see how others do it and learn possibly better
ways.
Please, please take a few minutes to clean it up and submit it.
Cheers,
Dave
OtterDad wrote:
>
> i have a generic include module that i actually named 'pulse' to keep
> track of other running programs. it uses shared memory instead of IPC.
> i can send it to privately if you'd like. i need to clean it up before
> submitting it to the archives. i didn't think anybody else would need
> it besides me.
>
> Yours, OtterDad
>
> Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
>
. .. : :: = == == = :: : .. .
Server-Side DB driven web sites,
Software Development
and part-time games developer
contact dave_p at purpletiger dot com
. .. : :: = == == = :: : .. .
11. Re: Interprocess Communication...
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 11, 2004
-
Last edited Nov 12, 2004
On Thu, 11 Nov 2004 08:22:32 -0800, OtterDad <guest at rapideuphoria.com> wrote:
> track of other running programs. it uses shared memory instead of IPC.
> i can send it to privately if you'd like. i need to clean it up before
> submitting it to the archives. i didn't think anybody else would need
> it besides me.
Sounds interesting.
What I think would be ideal would be an inter-process framework, that
can check whether another program is running or has had a run-time
error, can call functions and procedures in another running program
synchronously or asynchronously, and can share memory with other
programs.
A merger between ipc.ew, memshare.ew, and some other features.
Is it possible to do asynchronous function calls? How does call_back work?
--
MrTrick
12. Re: Interprocess Communication...
- Posted by OtterDad <otter at full-moon.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
Patrick Barnes wrote:
>
> On Thu, 11 Nov 2004 08:22:32 -0800, OtterDad <guest at rapideuphoria.com>
> wrote:
> > track of other running programs. it uses shared memory instead of IPC.
> > i can send it to privately if you'd like. i need to clean it up before
> > submitting it to the archives. i didn't think anybody else would need
> > it besides me.
>
>
> Sounds interesting.
>
> What I think would be ideal would be an inter-process framework, that
> can check whether another program is running or has had a run-time
> error, can call functions and procedures in another running program
> synchronously or asynchronously, and can share memory with other
> programs.
>
> A merger between ipc.ew, memshare.ew, and some other features.
>
> Is it possible to do asynchronous function calls? How does call_back work?
>
> --
> MrTrick
>
>
i'll put a package together this weekend and offer it up for Beta testing
Yours, OtterDad
Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
13. Re: Interprocess Communication...
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
On Fri, 12 Nov 2004 11:17:07 -0800, OtterDad <guest at rapideuphoria.com> wrote:
> > What I think would be ideal would be an inter-process framework, that
> > can check whether another program is running or has had a run-time
> > error, can call functions and procedures in another running program
> > synchronously or asynchronously, and can share memory with other
> > programs.
> >
> > A merger between ipc.ew, memshare.ew, and some other features.
> >
> > Is it possible to do asynchronous function calls? How does call_back work?
>
>
> i'll put a package together this weekend and offer it up for Beta testing
>
Ooh, that would be great!
Can you put a function in there - wait_for_event (or similar) that can
serve in place of win32lib's WinMain? Not every IPC program uses
win32lib.
--
MrTrick
