| SPAWN [message #8682] |
Tue, 08 April 1997 00:00  |
Nobuyuki Tasaka
Messages: 2
Registered: April 1997
|
Junior Member |
|
|
Hi all,
If someone who have tried to compare SPAWN in the following
usage, please let me know the difference in terms of data
parsing speed, interface flexibility and routine's independency.
I would like to use SPAWN for calling database retriving routine
written in C.
1) SPAWN, "cmd", result
2) SPAWN, "cmd", /UNIT
3) SPAWN, "cmd"
(C routine writes data to memory map file and then IDL read it
as a Logical Unit File)
I'm looking forward to your help.
Nobu
---------------------------------
Nobuyuki Tasaka
GE Medical Systems
3200 N Grandview Blvd,
Waukesha, WI 53188
(Phone) 414-521-6577
(E-mail) tasaka@mr.med.ge.com
---------------------------------
|
|
|
|
| Re: SPAWN [message #8723 is a reply to message #8682] |
Wed, 16 April 1997 00:00  |
alpha
Messages: 49
Registered: September 1996
|
Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> Nobuyuki Tasaka <tasaka@mr.med.ge.com> writes:
>> If someone who have tried to compare SPAWN in the following
>> usage, please let me know the difference in terms of data
>> parsing speed, interface flexibility and routine's independency.
>> I would like to use SPAWN for calling database retriving routine
>> written in C.
>>
>> 2) SPAWN, "cmd", /UNIT
> This method is much more flexible in terms of interaction with
> your database, but it is restricted to UNIX platforms. If you want
> to pass large amounts of data back and forth and can be slow and,
> of course,
ah yes, 130Kbyte/sec maximum
you have to make two copies of every piece of data,
> which is not resource friendly.
Call_External would probably be
> a better choice if you decided to go down this path. It would give
> you the ability to share memory resources with your database
> access program.
Call exeternal with FDDI - call by reference!
I made up to 8Mbytes/sec data transfer directly into IDL-arrays!
>> 3) SPAWN, "cmd"
>> (C routine writes data to memory map file and then IDL read it
>> as a Logical Unit File)
> This has several huge advantages. First, it is extremely simple
> to implement.
Really? can you tell something more about memory-map-Files?
is that a ramdisk-filesystem?
be aware that you will the problem of two copies of the same
data again!
You don't need any special knowledge about
> operating sytems, linking protocols, etc. And second, it works
> on every platform IDL supports. You don't have to write special
> code when you decide to port from your Suns to the PC or Mac.
> On the downside, if you are transferring large amounts of data
> it can be slower than you would like.
Ah.. si: how is the rate?
> If you are really serious about doing this, I would look into
> Call_External as a possibility. Or, perhaps even better, wait
> for IDL 5 and the new database connection tools. This problem
> may have already been solved for you! :-)
ah yes! ODBC is the best of course!
so, CU
Panther
--
Panther in the Jungle __..--''``\--....___ _..,_
-BELIEVE AND DECEIVE- _.-' .-/"; ` ``<._ ``-+'~=.
http://www.ang-physik _.-' _..--.'_ \ `(^) )
.uni-kiel.de/~hendrik ((..-' (< _ ;_..__ ; `'
|
|
|
|
| Re: SPAWN [message #8749 is a reply to message #8682] |
Fri, 11 April 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Nobuyuki Tasaka <tasaka@mr.med.ge.com> writes:
> If someone who have tried to compare SPAWN in the following
> usage, please let me know the difference in terms of data
> parsing speed, interface flexibility and routine's independency.
>
> I would like to use SPAWN for calling database retriving routine
> written in C.
>
> 1) SPAWN, "cmd", result
This is the least flexible way of using SPAWN, I think. You can
only ask one "question" at a time and then you have the problem
of parsing the "result" to get the answer you want.
> 2) SPAWN, "cmd", /UNIT
This method is much more flexible in terms of interaction with
your database, but it is restricted to UNIX platforms. If you want
to pass large amounts of data back and forth and can be slow and,
of course, you have to make two copies of every piece of data,
which is not resource friendly. Call_External would probably be
a better choice if you decided to go down this path. It would give
you the ability to share memory resources with your database
access program.
> 3) SPAWN, "cmd"
> (C routine writes data to memory map file and then IDL read it
> as a Logical Unit File)
This has several huge advantages. First, it is extremely simple
to implement. You don't need any special knowledge about
operating sytems, linking protocols, etc. And second, it works
on every platform IDL supports. You don't have to write special
code when you decide to port from your Suns to the PC or Mac.
On the downside, if you are transferring large amounts of data
it can be slower than you would like.
If you are really serious about doing this, I would look into
Call_External as a possibility. Or, perhaps even better, wait
for IDL 5 and the new database connection tools. This problem
may have already been solved for you! :-)
Cheers!
David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
2642 Bradbury Court, Fort Collins, CO 80521
Phone: 970-221-0438 Fax: 970-221-4762
E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
-----------------------------------------------------------
|
|
|
|
|
|
| Re: spawn [message #18943 is a reply to message #8682] |
Thu, 17 February 2000 00:00 |
marc schellens[1]
Messages: 183
Registered: January 2000
|
Senior Member |
|
|
Craig Markwardt wrote:
>
> marc <m_schellens@hotmail.com> writes:
>
>> I want to spawn under UNIX one program many times (multiprocessor
>> machine). So I could sent it into the background using the UNIT keyword,
>> but how can I determine when the program finishes?
>> I run some basic tests and it seems that IDL leaves the unit open.
>> Is there a way or have I (ab)use the filesystem for this (via
>> lockfiles)?
>
> A clarification is in order. SPAWN with the UNIT keyword does *not*
> run the process in the background. The unit stays open because IDL
> attaches the output of the process to the unit, and IDL is waiting for
> you to read the output.
>
> You can run the process in the background by adding '&' like you
> normally would. Then be sure that you redirect the output and CLOSE
> the unit.
>
> To find out whether a background process is finished is difficult.
> Usually it's just easiest to write a flag to a temporary file when the
> job is done, and have IDL periodically monitor that file for changes.
> One can probably do it with the unix system call waitpid(), but you
> that would require compiling a DLM, not for the faint of heart.
>
> Good luck,
> Craig
The & at the end does only work in shell mode. Wiht SPAWN,/NOSHELL,...
you get an error message because the process treats it as an option. but
with SPAWN,/NOSHELL,UNIT=u,... IDL returns immediatly back to the
command line (also without /NOSHELL), or continues execution (at least
under Solaris and Linux, IDL 5.2).
But even then fstat(u) doesn't tell you anything about the process
status. Al least you can kill the process with FREE_LUN,u .
Right now I spawn every some seconds a 'ps' command and compare the
pid's (from PID parameter) to see if the process is already running.
But this 'ps' bothers, since the behaviour is little different between
Solaris and Linux.
However, thanks,
:-) marc
|
|
|
|
| Re: spawn [message #18945 is a reply to message #8682] |
Wed, 16 February 2000 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
marc <m_schellens@hotmail.com> writes:
> I want to spawn under UNIX one program many times (multiprocessor
> machine). So I could sent it into the background using the UNIT keyword,
> but how can I determine when the program finishes?
> I run some basic tests and it seems that IDL leaves the unit open.
> Is there a way or have I (ab)use the filesystem for this (via
> lockfiles)?
A clarification is in order. SPAWN with the UNIT keyword does *not*
run the process in the background. The unit stays open because IDL
attaches the output of the process to the unit, and IDL is waiting for
you to read the output.
You can run the process in the background by adding '&' like you
normally would. Then be sure that you redirect the output and CLOSE
the unit.
To find out whether a background process is finished is difficult.
Usually it's just easiest to write a flag to a temporary file when the
job is done, and have IDL periodically monitor that file for changes.
One can probably do it with the unix system call waitpid(), but you
that would require compiling a DLM, not for the faint of heart.
Good luck,
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
|
|
| Re: Spawn [message #61778 is a reply to message #8682] |
Thu, 31 July 2008 10:21 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On Jul 31, 6:37 am, Joost Aan de Brugh <joost...@gmail.com> wrote:
> Hello Allan,
>
> This works well. And with the Current=olddir in the cd (and then
> cd,olddir at the end) it is entirely solved.
Yes, the most used routine in my library is:
pro pwd
cd, current=c
print, c
end
Mike
--
www.michaelgalloy.com
Tech-X Corporation
Software Developer II
|
|
|
|
| Re: Spawn [message #61789 is a reply to message #8682] |
Thu, 31 July 2008 05:38 |
mankoff
Messages: 131
Registered: March 2004
|
Senior Member |
|
|
On Jul 31, 7:44 am, Joost Aan de Brugh <joost...@gmail.com> wrote:
> Hello all,
>
> I was wondering if you can navigate efficiently through directories
> with Spawn (Calling shell commands)
>
> For example:
> IDL> Spawn,"pwd"
> <Some directory>
> IDL> Spawn,"cd .."
> IDL> Spawn,"pwd"
> <Still same directory, because after the cd .., something is reset>
>
> I solved this problem by making an executable file which takes care of
> the directories.
> Spawn,condition?"OneFile":"OtherFile"
> And the executable file OneFile and OtherFile do the same but in a
> slightly different directory.
>
> I actually have no problem with this, but I was wondering if there is
> a nicer way to do this.
>
> Kind regards,
> Joost
You can use the internal 'cd' command in IDL:
IDL> spawn, 'foo'
IDL> cd, '..'
IDL> spawn, 'foo' ; different foo, in parent directory.
|
|
|
|
| Re: Spawn [message #61790 is a reply to message #8682] |
Thu, 31 July 2008 05:37 |
Joost Aan de Brugh
Messages: 16
Registered: July 2008
|
Junior Member |
|
|
Hello Allan,
This works well. And with the Current=olddir in the cd (and then
cd,olddir at the end) it is entirely solved.
Thanks.
Joost
>
> Joost,
>
> Use the IDL cd procedure:
>
> IDL> spawn,'pwd'
> /home/allan
> IDL> cd,'..'
> IDL> spawn,'pwd'
> /home
>
> Thanks,
>
> Allan
|
|
|
|
| Re: Spawn [message #61791 is a reply to message #8682] |
Thu, 31 July 2008 05:33 |
Bob[3]
Messages: 60
Registered: December 2006
|
Member |
|
|
On Jul 31, 7:44 am, Joost Aan de Brugh <joost...@gmail.com> wrote:
> Hello all,
>
> I was wondering if you can navigate efficiently through directories
> with Spawn (Calling shell commands)
>
> For example:
> IDL> Spawn,"pwd"
> <Some directory>
> IDL> Spawn,"cd .."
> IDL> Spawn,"pwd"
> <Still same directory, because after the cd .., something is reset>
I believe the problem is because each time SPAWN is executed a new
shell is opened, so that you will be in IDL's current working
directory by default.
|
|
|
|
| Re: Spawn [message #61792 is a reply to message #8682] |
Thu, 31 July 2008 04:56 |
Allan Whiteford
Messages: 117
Registered: June 2006
|
Senior Member |
|
|
Joost Aan de Brugh wrote:
> Hello all,
>
> I was wondering if you can navigate efficiently through directories
> with Spawn (Calling shell commands)
>
> For example:
> IDL> Spawn,"pwd"
> <Some directory>
> IDL> Spawn,"cd .."
> IDL> Spawn,"pwd"
> <Still same directory, because after the cd .., something is reset>
>
> I solved this problem by making an executable file which takes care of
> the directories.
> Spawn,condition?"OneFile":"OtherFile"
> And the executable file OneFile and OtherFile do the same but in a
> slightly different directory.
>
> I actually have no problem with this, but I was wondering if there is
> a nicer way to do this.
>
> Kind regards,
> Joost
Joost,
Use the IDL cd procedure:
IDL> spawn,'pwd'
/home/allan
IDL> cd,'..'
IDL> spawn,'pwd'
/home
Thanks,
Allan
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
