I have a member in my group that used Photon functions for non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
Hello Biren
Can you give a little more information on this subject? Maybe explain
what they used them for and what was used?
Thanks
Rodney
Biren Mehta <cybermedconsulting@yahoo.com> wrote:
I have a member in my group that used Photon functions for non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
Well,
The best example I can think of is using PtSpawn() instead of Spawn() to
spawn a process that has nothing to do with Photon.
Let me know if this helps
“Gui Group” <gui@qnx.com> wrote in message news:9tgrr8$ph7$1@nntp.qnx.com…
Hello Biren
Can you give a little more information on this subject? Maybe explain
what they used them for and what was used?Thanks
Rodney
Biren Mehta <> cybermedconsulting@yahoo.com> > wrote:
I have a member in my group that used Photon functions for non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
Hey Biren
Are you running Photon at all? In other words are they using PtSpawn inside
of a Photon application to spawn a non-photon application, or are you using
PtSpawn inside of a non-photon application to try and spawn a non-photon
application? Because the latter just won’t work due to the following reasons:
PtSpawn() calls PtAppAddSignalProc(), which will not work unless you
have initialized the Photon library using PtInit() or equivalent.
PtInit() will fail unless you’re running Photon.
PtSpawn() will not give you a callback when the child process terminates
unless you’re running PtMainLoop() or equivalent.
The requirement that you must call PtInit() and PtMainLoop() pretty much
turns your application into a Photon application.
Now if you were doing the former which is the spawning of a non-photon
application from a photon appication there are some advantages that
come with PtSpawn. The first advantage is that you can set up a callback
to be called when the spawned process terminates. This is good to have if
you have to accomplish some specific task after the spawned process exits.
Another advantage is that you can re-route input and output using the
PtSpawnOptions_t structure. This way you can setup input and output
handlers without having to do dup the input and output fd’s. If you
are going to be Spawning processes from a Photon application then using
PtSpawn is definitely the way to go.
Thanks
Rodney
Biren Mehta <cybermedconsulting@yahoo.com> wrote:
Well,
The best example I can think of is using PtSpawn() instead of Spawn() to
spawn a process that has nothing to do with Photon.
Let me know if this helps“Gui Group” <> gui@qnx.com> > wrote in message news:9tgrr8$ph7$> 1@nntp.qnx.com> …
Hello BirenCan you give a little more information on this subject? Maybe explain
what they used them for and what was used?Thanks
Rodney
Biren Mehta <> cybermedconsulting@yahoo.com> > wrote:
I have a member in my group that used Photon functions for non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
Hi,
I thought of another example that I would like you to comment on:
We have an application and interface that contains one main process (client)
and 5 other processes (servers). One of the servers is the GUI process. The
other processes have nothing to do with the GUI.
There are two options that I see of for structuring the communication.
(1) Set up resource managers for each process and communicate via msgSend
and msgReceive.
(2) Use PtMessageSend in all the processes to communicate with one another.
This can be done if each process includes the photon libraries. A member of
our group has tried this and it works okay.
To me it doesn’t seem right to use Pt… in any non-photon process.
However, it seems a lot easier to use PtMessageSend than to set up resource
managers. I am sure there must be drawbacks to doing it that way (such as
overhead), but I’m not sure what all the major drawbacks are.
Thanks
----- Original Message -----
From: “Gui Group” <gui@qnx.com>
Newsgroups: qdn.public.qnxrtp.photon
Sent: Thursday, November 22, 2001 8:19 AM
Subject: Re: Using Photon Functionality for Non-Photon Stuff
Hey Biren
Are you running Photon at all? In other words are they using PtSpawn
inside
of a Photon application to spawn a non-photon application, or are you
using
PtSpawn inside of a non-photon application to try and spawn a non-photon
application? Because the latter just won’t work due to the following
reasons:PtSpawn() calls PtAppAddSignalProc(), which will not work unless you
have initialized the Photon library using PtInit() or equivalent.PtInit() will fail unless you’re running Photon.
PtSpawn() will not give you a callback when the child process terminates
unless you’re running PtMainLoop() or equivalent.The requirement that you must call PtInit() and PtMainLoop() pretty much
turns your application into a Photon application.
Now if you were doing the former which is the spawning of a non-photon
application from a photon appication there are some advantages that
come with PtSpawn. The first advantage is that you can set up a callback
to be called when the spawned process terminates. This is good to have if
you have to accomplish some specific task after the spawned process exits.
Another advantage is that you can re-route input and output using the
PtSpawnOptions_t structure. This way you can setup input and output
handlers without having to do dup the input and output fd’s. If you
are going to be Spawning processes from a Photon application then using
PtSpawn is definitely the way to go.Thanks
RodneyBiren Mehta <> cybermedconsulting@yahoo.com> > wrote:
Well,
The best example I can think of is using PtSpawn() instead of Spawn() to
spawn a process that has nothing to do with Photon.
Let me know if this helps“Gui Group” <> gui@qnx.com> > wrote in message
news:9tgrr8$ph7$> 1@nntp.qnx.com> …
Hello BirenCan you give a little more information on this subject? Maybe explain
what they used them for and what was used?Thanks
Rodney
Biren Mehta <> cybermedconsulting@yahoo.com> > wrote:
I have a member in my group that used Photon functions for
non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
\
“Gui Group” <gui@qnx.com> wrote in message news:9tj8iv$bko$1@nntp.qnx.com…
Hey Biren
Are you running Photon at all? In other words are they using PtSpawn
inside
of a Photon application to spawn a non-photon application, or are you
using
PtSpawn inside of a non-photon application to try and spawn a non-photon
application? Because the latter just won’t work due to the following
reasons:PtSpawn() calls PtAppAddSignalProc(), which will not work unless you
have initialized the Photon library using PtInit() or equivalent.PtInit() will fail unless you’re running Photon.
PtSpawn() will not give you a callback when the child process terminates
unless you’re running PtMainLoop() or equivalent.The requirement that you must call PtInit() and PtMainLoop() pretty much
turns your application into a Photon application.
Now if you were doing the former which is the spawning of a non-photon
application from a photon appication there are some advantages that
come with PtSpawn. The first advantage is that you can set up a callback
to be called when the spawned process terminates. This is good to have if
you have to accomplish some specific task after the spawned process exits.
Another advantage is that you can re-route input and output using the
PtSpawnOptions_t structure. This way you can setup input and output
handlers without having to do dup the input and output fd’s. If you
are going to be Spawning processes from a Photon application then using
PtSpawn is definitely the way to go.Thanks
RodneyBiren Mehta <> cybermedconsulting@yahoo.com> > wrote:
Well,
The best example I can think of is using PtSpawn() instead of Spawn() to
spawn a process that has nothing to do with Photon.
Let me know if this helps“Gui Group” <> gui@qnx.com> > wrote in message
news:9tgrr8$ph7$> 1@nntp.qnx.com> …
Hello BirenCan you give a little more information on this subject? Maybe explain
what they used them for and what was used?Thanks
Rodney
Biren Mehta <> cybermedconsulting@yahoo.com> > wrote:
I have a member in my group that used Photon functions for
non-photon
processes? I understand that this is not how the system is designed,
however, I don’t fully understand the drawbacks to his method.
\
Biren Mehta wrote:
Hi,
I thought of another example that I would like you to comment on:We have an application and interface that contains one main process (client)
and 5 other processes (servers). One of the servers is the GUI process. The
other processes have nothing to do with the GUI.There are two options that I see of for structuring the communication.
(1) Set up resource managers for each process and communicate via msgSend
and msgReceive.
(2) Use PtMessageSend in all the processes to communicate with one another.
This can be done if each process includes the photon libraries. A member of
our group has tried this and it works okay.To me it doesn’t seem right to use Pt… in any non-photon process.
Your are correct that PtMessageSend() from (as you describe your
application) a “server” to your client is (to paraphrase) “not right”;
however, the reason it is “not right” is that it violates the universal
(in client/server computing) rule that a server should never block on a
client.
I am not sure what the implication of using the Photon cover functions
in a non-Photon app are, but I am quite sure that
MsgSend/MsgReceive/MsgReply are fundamentally no more complex than the
equivalent Photon covers (when used outside of a Photon app).
However, it seems a lot easier to use PtMessageSend than to set up resource
managers. I am sure there must be drawbacks to doing it that way (such as
overhead), but I’m not sure what all the major drawbacks are.
You don’t need to write a resource manager in order to implement a
server (without using the Photon libs). MsgReceive/MsgReply/MsgSendPulse
will work just fine outside of the resmgr framework; OTOH, writing
resource manager isn’t as complicated as you imply (QSSL has done much
work to make it almost trivial - a /dev/null RM is indeed trivial).
My personal bent would be to implement using resource managers and
Photon clients (option 1 above).