Forum OpenACS Q&A: Is it possible to use the native exec command while also using nsproxy?

Collapse
1: Is it possible to use the native exec command while also using nsproxy?
Posted by Colin Charbonneau on 10/30/13 09:47 PM
Taking a look at the acs-tcl/tcl/proxy-procs.tcl file, there is a wrapper for exec which moves on to proxy::exec in order to use nsproxy for exec calls. This is fine and desired.

However, in certain cases, I want to be able to use the original exec command. I see that that exec was renamed to real_exec, but that command is not usable outside of the scope of that file, only when NaviServer first loads.

Is there a solution where I can have the best of both worlds? I'd like to use exec as is and either have another command that performs the original exec's function, or perhaps a flag or parameter to pass to achieve the same thing.

Collapse
2: Re: Is it possible to use the native exec command while also using nsproxy? (response to 1)
Posted by Gustaf Neumann on 10/31/13 09:56 AM
As you wrote, there is - out of the box - currently no way to access the original exec in connection threads. You can certainly comment out the last command of acs-tcl/tcl/proxy-procs.tcl and call "proxy::exec" or "exec" depending on your needs.

however, i am wondering, what the certain cases are, where you want to call the original exec?

Collapse
3: Re: Is it possible to use the native exec command while also using nsproxy? (response to 2)
Posted by Colin Charbonneau on 10/31/13 02:05 PM
I have an infinite loop that waits on a blocking perl script, and sometimes it can iterate extremely quickly, causing deadlocks.
Collapse
4: Re: Is it possible to use the native exec command while also using nsproxy? (response to 3)
Posted by Gustaf Neumann on 10/31/13 07:02 PM
It is probably better to do the iterations in a script rather than doing multiple execs from the connection threads. not sure, this is possible in your situation.

Unfortunately, tcl's "interp alias" does not help to preserve the original exec command. The only way i found was to use the "alias" method of xotcl2/nsf. If that's an option for you I'll summarize how to this.

Collapse
5: Re: Is it possible to use the native exec command while also using nsproxy? (response to 4)
Posted by Colin Charbonneau on 11/01/13 04:47 PM
I would normally agree, but the code in the perl script cannot be done in tcl reasonably.
Collapse
6: Re: Is it possible to use the native exec command while also using nsproxy? (response to 5)
Posted by Gustaf Neumann on 11/01/13 11:15 PM
i was not suggesting to replace the perl stuff by tcl. In case you have a quick loop with many execs of the form 
   while {...} {
      set x [exec perl script.pl]
   }
it would be better to make yet another script containing the loop + call of the perl script, and call this additional script via a single exec.
Collapse
7: Re: Is it possible to use the native exec command while also using nsproxy? (response to 6)
Posted by Colin Charbonneau on 11/04/13 09:30 PM
I see what you mean.

I'm not sure if that is possible in this case. After the perl script returns, it outputs a string containing a file path and then is passed to a different proc. If my perl script never returns, I can never pass it back to the tcl?

I'm left wondering about the nature of the deadlock error within proxy::exec. Is it some sort of timing issue that can be solved with a sleep command? If you have any information on how this happens, that would be greatly appreciated.

Collapse
8: Re: Is it possible to use the native exec command while also using nsproxy? (response to 7)
Posted by Gustaf Neumann on 11/05/13 03:30 PM
i have never seen proxy::exec leading to a deadlock. How are you handling the situation when the perl script never returns? ns_proxy (the machinery used by proxy::exec) has several timeouts [1]. Can it be that your server is running out of slaves? Are you using AOLserver or NaviServer?

-gn
[1] http://naviserver.sourceforge.net/n/nsproxy/files/ns_proxy.html