| Author |
Message |
Henrik Johansson
Guest
|
 Posted:
Thu Sep 02, 2004 9:22 pm Post subject:
IPC problems |
|
|
I'm trying to write an interface to Grace (a plotting tool) in SKILL.
The communication with the Grace process is handled by SKILL's IPC
functions.
The new plot functions are working beautifully unless they sends too
much data too fast to the child process. Since the ipcWriteProcess
function is non-blocking I suspect that the data is buffered at the
parent side when the child gets more data than it can chew. If the
parent sleeps for a second and then sends another command to the child,
the missing data is written out before the new command.
Anyone know of a blocking alternative to ipcWriteProcess?
Regards
Henrik Johansson
|
|
| Back to top |
|
 |
Andrew Beckett
Guest
|
| Posted:
Fri Sep 03, 2004 7:42 am Post subject:
Re: IPC problems |
|
|
Hi Henrik,
I'm not sure that would solve your problem. ipcWriteProcess() does an
unbuffered write (or at least it flushes its buffers after a write) - but any
data which is unread by the child would still be sitting there in the pipe
waiting to be read, I'd have thought.
It sounds like the problem is on the child side - the child is not correctly
reading its input commands if a new command is sent whilst it is still
processing.
You may be able to get around this by getting the child to send something back
to DFII (i.e. some sort of handshaking) so that your SKILL code doesn't try
to send a command until it knows it is OK to do so.
Or you may be able to put some kind of wrapper around grace (perhaps using
expect?) to make it behave better?
Andrew.
On Thu, 02 Sep 2004 19:22:53 +0200, Henrik Johansson <henjo@ieee.org> wrote:
| Quote: | I'm trying to write an interface to Grace (a plotting tool) in SKILL.
The communication with the Grace process is handled by SKILL's IPC
functions.
The new plot functions are working beautifully unless they sends too
much data too fast to the child process. Since the ipcWriteProcess
function is non-blocking I suspect that the data is buffered at the
parent side when the child gets more data than it can chew. If the
parent sleeps for a second and then sends another command to the child,
the missing data is written out before the new command.
Anyone know of a blocking alternative to ipcWriteProcess?
Regards
Henrik Johansson
|
--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd |
|
| Back to top |
|
|
Henrik Johansson
Guest
|
| Posted:
Fri Sep 03, 2004 10:51 pm Post subject:
Re: IPC problems |
|
|
Andrew Beckett wrote:
| Quote: | You may be able to get around this by getting the child to send something back
to DFII (i.e. some sort of handshaking) so that your SKILL code doesn't try
to send a command until it knows it is OK to do so.
|
First I wrote a wrapper in perl and it worked, but with each line being
acknowledged it became very slow (like 3 lines per second).
So I tried a different approach with named pipes instead. And now with
the pipe handling the bufferering, things works perfectly. So if anyone
is interrested in a Grace interface for Skill I can publish the code in
the newsgroup.
Regards
Henrik
|
|
| Back to top |
|
|
Erik Wanta
Guest
|
| Posted:
Sat Sep 04, 2004 5:43 pm Post subject:
Re: IPC problems |
|
|
Henrik:
Please publish.
---
Erik
Henrik Johansson <henjo@ieee.org> wrote in message news:<chaeek$7ad$1@news.island.liu.se>...
| Quote: | Andrew Beckett wrote:
You may be able to get around this by getting the child to send something back
to DFII (i.e. some sort of handshaking) so that your SKILL code doesn't try
to send a command until it knows it is OK to do so.
First I wrote a wrapper in perl and it worked, but with each line being
acknowledged it became very slow (like 3 lines per second).
So I tried a different approach with named pipes instead. And now with
the pipe handling the bufferering, things works perfectly. So if anyone
is interrested in a Grace interface for Skill I can publish the code in
the newsgroup.
Regards
Henrik |
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in