"Craig A. Berry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > At 11:41 AM -0600 5/29/03, Michael Downey wrote: > > >You shouldn't have to set up mailbox piping because the system() call is a > >blocking call. Therefore, any sharing of file I/O is not an issue as there > >shouldn't be a way to system() off a large number of process all reading > >from the same file. > > Though safe_popen implements pipes for piped open() as well as for system() and backticks. > > > > >> My own opinion is that when you do system(), the subprocess shouldn't > >> be taking any input from sys$input at all...it should have it's input > >> set to NL: ... if you want a subprocess that gets input, you should > >> be using open(X,'|some_command'). > >> > >What about when you are writing an interactive script and you want to call a > >program that also is interactive? > > We do currently support that by inheriting SYS$COMMAND from the parent. > But how do you tell perl to use SYS$COMMAND instead of SYS$INPUT, besides changing VMSPIPE.COM to do the redirection for you? And without breaking compatiablity in the script?
> >subprocess should inherit stdin, stdout and stderr. And they will > >unless you wrap them in a DCL script. > > Hmm. I think once you are running a DCL procedure you are implicitly asking that SYS$INPUT be the command procedure, though SYS$COMMAND remains your terminal for an interactive session. For example: > > $ type foo.com > $ show logical sys$input > $ show logical sys$command > $ @foo > "SYS$INPUT" = "_BRIANA$DKB100:" (LNM$PROCESS_TABLE) > "SYS$COMMAND" = "_BRIANA$TNA21:" (LNM$PROCESS_TABLE) > Ah, but I'm not requesting a DCL script to be run. I'm requesting a perl script to be run, which behind the scenes causes a DCL script to be run. This comes back to the different views of SYS$INPUT and STDIN. DCL has a seperation of SYS$INPUT and SYS$COMMAND, but from my understanding Perl does not. The reason Perl does not is because C does not. It all comes down to how you want Perl to behave. If you want Perl to behave like DCL then I would say that my whole arguement is wrong. But if you want it to behave like C then my arguement is valid. > However, this is not necessarily an argument against your approach, since the logical redefinitions that take place in vmspipe.com are user-mode and will persist only for the execution of the piped command and thus shouldn't confuse DCL in reading the rest of the .COM file. > > In fact, a more low-tech way to get the behavior you are looking for might be to put > > $ define/user_mode sys$input sys$command > > into vmspipe.com. I guess that would look something like the following, though I haven't tested this: > > --- vmspipe.com Sat May 24 00:49:00 2003 > +++ new_vmspipe.com Thu May 29 13:24:59 2003 > @@ -6,7 +6,10 @@ > $ perl_del = "delete" > $ pif = "if" > $! --- define i/o redirection (sys$output set by lib$spawn) > -$ pif perl_popen_in .nes. "" then perl_define/user/name_attributes=confine sys$input 'perl_popen_in' > +$ pif perl_popen_in .nes. "" > +$ then perl_define/user/name_attributes=confine sys$input 'perl_popen_in' > +$ else perl_define/user/name_attributes=confine sys$input sys$command > +$ endif > $ pif perl_popen_err .nes. "" then perl_define/user/name_attributes=confine sys$error 'perl_popen_err' > $ pif perl_popen_out .nes. "" then perl_define sys$output 'perl_popen_out' > $! --- build command line to get max possible length > [eop] > I think that would be a decent approach as well. I will try that and let you know how it works. > > > Also why don't we use the C RTL > >routines? Both system() and popen() are available. I do know that prior to > >version 7.2 of VMS many of the C RTL routines are missing or have problems, > >but in the current version of VMS the C RTL seems to be well supported and > >has most of the bugs worked out of it. > > Yes, there has been *huge* improvement in the C RTL in recent years, but the piping implementation was still very buggy as of 7.2. Previous to Perl 5.6.1 we were using the C RTL for popen(), but a lot of piped I/O was just hanging in various deadlock conditions. Chuck cooked up what we currently have to get around these problems. It works rather well and has the added advantage of working on older VMS versions, which he and a lot of other people still use. Long term I'd like to see his piping implementation configurable so that with the flip of a switch we could get either his version or the C RTL version. That way if the C RTL version is ever better, we can use it when and where available. > > >Really I'm coming from the point of view of portability. If Perl doesn't > >work similar on one platform as it does on the other then I'd say we are > >losing a large part of what makes Perl so great. > > I think we're all in agreement about that. How to get there is not always as clear as it could be. > My only reason for bringing up the C RTL is that we've already gone through the process of writing a portable I/O, Thread, Process, Environment, etc.. library. We initially used lib$spawn and ASTs and such in our process portion and ran into numerous issues. I believe the Perl implementation is far better than what ours was but it also is a lot more code. We now have very little differences between our VMS and UNIX implementation in the process library. This doesn't mean it was easy and there are a number of things that aren't 100% but they are fairly minor. Also I don't believe that supporting anything before VMS 7.2 would be very managable if we went to the C RTL just from my experience. I haven't really done anything with 7.2 in a long while so I don't know if things are fixed or not. One of the things that might be worth checking again is wether or not the TCPIP reads are process blocking anymore. I found that doing a read in a thread would block the whole process not just the one thread. That was over a year ago and the problem went away once we moved to 7.3 so I don't know if it still happens, but definitely should be something looked at now VMS Perl supports multi-threads. Also I would think using multi-threads and AST QIOs might be a bit risky especially on a multicpu server. We were running into timing issues when we were trying to use timed QIO reads on sockets. The problem got a lot simpiler once we moved to using the C reads and writes. I'm not saying it can't be done but 20 lines of code is a lot easier to manage than 200. > >I'm hoping for more input on this problem as I have just recently started > >looking into the guts of VMS Perl. I have programmed on VMS extensively but > >would think that others would be more familiar with the VMS code. Right now > >we only have systems running 7.2 or better and we likely will be moving > >everything to 7.3-1 as it seems to have the best support for threads and the > >C RTL. So testing on earlier versions is a bit hard for me. > > Thanks for getting involved. I think we should do something along the lines you are suggesting, but this can get to be pretty twisty stuff so don't be put off if we want to discuss a bit before committing to a particular solution. > -- Don't get me wrong. I think this is a very complicated portion of code wrought with many strange and suprising things. I personally wouldn't want my change put in as is as I haven't the knowledge of the code, and now that I've moved away from using the SYS$QIO approach I probably wouldn't be the best canidate for maintaining the compatiablity with older code. Michael Downey MegaSys Computer Technologies
