HI,
Kyle,
The "Init Module" and "terminate Module" are functions that are
automatically called at the load and unload of a framework
respectively. I cannot call them explicitly from the application
that has been linked with a framework.
I would like to further add a point, this module of mine was
initially deployed on 10.2, and there I did not face any such
problem. Does this mean that there is some difference between OSX
10.2 and 10.4 that has given rise to this problem????
Regards,
Upasana
-----Original Message-----
From: unix-porting-bounces+upasanas=email@hidden
Is your application multi-threaded? You might be running into a
threading problem with your framework.
When you fork(), only the thread calling fork() lives on in the new
process. If your framework has its own threads, they'll disappear.
Also, I'm not sure what you mean by "unload".
The parent is definitely going to exit (based on your code fragment),
so in the parent process, the framework will unload, and I would
expect the "TERMINATE MODULE frmwrk" to be coming from *that*
process, not the child.
Perhaps you can "INIT_MODULE frmwrk" after you fork?
Kyle
-----Original Message-----
From: Upasana Sharma
Hi ,
Thanks Terry/Kevin for your inputs.
Let me first explain my components. We have a hardware that is being
accessed through a framework (which I mentioned gets exited at the
fork call). To use the functionality of the hardware we support both
network and standalone modes. For network mode, we have a server
module (that serves remote clients), which we need to run as a
daemon/background process. Thus the use of "exec" is ruled out here.
Terry, following your advice, I tried using daemon call, however, it
results in almost the same behaviour. The framework gets exited just
after the "daemon" call.
I could not understand how to keep the reference count, are you
talking about keeping a reference count inside the framework??
For your query about whether the child process continues, yes it
does, because all we want is to make the server run as a background
process. So just after calling fork we do the normal processing for
the server module in the child process. However at any place where
the server module tries to talk to the hardware, it fails since the
framework has exited along with the parent process. Can we stop this
from happening, i.e., association of framework with parent process???
An alternate solution that I can see is to load the framework
dynamically instead of linking the server with it, if thats
possible. Any comments? Do I need to make it a bundle for that???
Regards,
Upasana
> >
> > I have an application that is linked to a framework (created by
> > me). When this runs as an ordinary application, things work fine.
> > However, if I try to make this application a daemon by calling
fork
> > (), the framework gets unloaded as soon as the parent process
> > exits. It can be explained further by the code I use, as shown
> below -
> >
> > if ( (childpid = fork()) < 0 )
> > exit(-1);
> > else if (childpid > 0){
> > printf("\n parent is exiting, child will continue....");
> > exit(0); // Parent returns and framework also gets unloaded.
> > }
> >
> > When I run my application, the following stuff gets printed -
> > INIT_MODULE framwork
> > parent is exiting, child will continue....
> > TERMINATE_MODULE frmwrk
> >
> > This results in error to any function call of my framework from
the
> > child process since the framework has already been unloaded.
> >
> > Has anyone faced this before ? Is there a soution to this?? Can
> > there be a way through which I can delay the loading of my
> > framework to its first function call??
> >
> > Looking forward to some help!!!
> >
> > Regards,
> > Upasana
>
>
> The information contained in this electronic mail transmission may
> be privileged and confidential, and therefore, protected from
> disclosure. If you have received this communication in error, please
> notify us immediately by replying to this message and deleting it
> from your computer without copying or disclosing it.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Unix-porting mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
The information contained in this electronic mail transmission may
be privileged and confidential, and therefore, protected from
disclosure. If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer without copying or disclosing it.
