SKIL, IPC, asynchronous mode: How to pass information to the

[François]

Hello,

From the SKILL IPC documentation, the exit handler only accepts two
parameters: o_childId and x_exitStatus.

Is there a way to pass additional information?

By way of example, imagine that ipcBeginProcess is launched from a
banner menu using asynchronous communication. This allows users to
ignitiate several processes in parallel from different windows. The
issue is to let the termination handler know the ID of the window from
which the process was started.

Merci,

François

 

[S. Badel]

Hello Francois,

I would suggest using a global array, indexed by the child id. This is the one parameter that the
launcher and callbacks know in common.


Cheers,
Stéphane

François wrote:

Hello,

From the SKILL IPC documentation, the exit handler only accepts two
parameters: o_childId and x_exitStatus.

Is there a way to pass additional information?

By way of example, imagine that ipcBeginProcess is launched from a
banner menu using asynchronous communication. This allows users to
ignitiate several processes in parallel from different windows. The
issue is to let the termination handler know the ID of the window from
which the process was started.

Merci,

François

 

[Riad KACED]

Salut François,

A global variable will do the job as mentioned earlier by Stéphane.
There is a way to avoid Global variable though, please look at Source
Link Solution # 11239406. The given Solution is Skill++ based.

A+
Riad.

 

[eyn]

On Jun 16, 7:33 am, Riad KACED <riad.ka...@gmail.com> wrote:

Salut François,

A global variable will do the job as mentioned earlier by Stéphane.
There is a way to avoid Global variable though, please look at Source
Link Solution # 11239406. The given Solution is Skill++ based.

A+
Riad.

Is there any real benefit of avoiding global variables by going with
the Skill++ solution to justify the amount of extra coding and
debugging required to get it working?

The Skill++ approach seems pretty complicated IMO. I think you are
safe to use global variable if you prefix your global variable and try
to make it an associative table so all of your interprocess data can
be stored under just one global variable name, e.g.

myGlobalVar = makeTable( "myGlobalVar" nil )
myGlobalVar["var1"] = 1
myGlobalVar["var2"] = "abc"

 

[Andrew Beckett]

eyn wrote, on 06/16/09 21:43:

On Jun 16, 7:33 am, Riad KACED <riad.ka...@gmail.com> wrote:
Salut François,

A global variable will do the job as mentioned earlier by Stéphane.
There is a way to avoid Global variable though, please look at Source
Link Solution # 11239406. The given Solution is Skill++ based.

A+
Riad.

Is there any real benefit of avoiding global variables by going with
the Skill++ solution to justify the amount of extra coding and
debugging required to get it working?

The Skill++ approach seems pretty complicated IMO. I think you are
safe to use global variable if you prefix your global variable and try
to make it an associative table so all of your interprocess data can
be stored under just one global variable name, e.g.

myGlobalVar = makeTable( "myGlobalVar" nil )
myGlobalVar["var1"] = 1
myGlobalVar["var2"] = "abc"

Well, I guess I'm a bit biased since I wrote the solution that Riad's referring
to. If you just take that solution and use it as is, it's effectively a package.
You don't need to worry about how it works, and can just continue to write your
functions in SKILL. The example I give in the solution is:

(procedure MYdataHandler(ipcId data dpl)
dpl->count=dpl->count+1
dpl->table[dpl->count]=data
)

(procedure MYexitHandler(ipcId status dpl)
printf("Exited with status %d\n" status)
printf("%d items were read, contents of table:\n" dpl->count)
for(i 1 dpl->count
printf("Item %d:\n%s\n" i dpl->table)
)
)

CCSipcBeginProcessWithUserData(
"/bin/ls /bin" "" 'MYdataHandler nil 'MYexitHandler
list(nil 'count 0 'table makeTable('ipcOutput))
)

I happen to be passing a disembodied property list to the
CCSipcBeginProcessWithUserData function, which gets updated in the data handler,
and then the contents displayed in the exit handler. That's not really complicated?

The benefit of doing this is that you can have several IPC processes running in
parallel, each keeping track of their own data. You could do this with a global
table, indexed by the IPC id, but you need to make sure you clean up after
yourself. It doesn't strike me that this would be any easier than using the
solution provided.

If you had to write it yourself, then maybe I'd agree - although it's not
exactly difficult... most of the complexity is just having methods to allow you
to specify the handlers in a variety of different ways. You don't strictly need
to do that - I was just trying to make the solution more comprehensive.

Regards,

Andrew.


--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)