While we are puttering along here, halfway between Perl 5.8.4 and 5.8.5, and a year or three away from Perl 6, I thought I should try to do a state of the disunion and sum up some of the major and minor areas where the VMS port of Perl needs work. Perl on VMS is about 10 years old now, and both Perl and VMS have come a long way since then. In some areas Perl needs to catch up with today's VMS and CRTL, and in other areas, Perl on VMS needs to catch up with (or take advantage of) more recent Perl innovations on other platforms. In still other areas, the CRTL still has bugs and/or missing features and we need to reevaluate our workarounds and improve or replace them when we can.
The list below is simply in the order it occurred to me. Needless to say, I am not going to get all these things done by myself, so if you see a piece you'd like to take on, please speak up. The list is also not necessarily complete, but I thought it best to get it out there rather then keep lengthening it indefinitely. Apologies in advance for the length of this message. Table of Contents: 1.) New and/or improved pipe implementation. 2.) New and/or improved system() and backticks implementation. 3.) ODS-5 filename support. 4.) Support for the C++ compiler. 5.) Evaluate building with Configure under GNV rather than configure.com under DCL. 6.) Evaluate porting the pthread-based Win32 pseudo-fork. 7.) Signal handling improvements and fixes. 8.) Port Test::Smoke to VMS. 9.) Enable support for new CRTL functions in VMS 7.3-x. 10.) Support ODS-5's POSIX volume characteristics (e.g. access dates) And more details on those items: 1.) New and/or improved pipe implementation. First of all, a reminder of what's wrong with what we've got,and what's even more wrong with the CRTL implementation it replaces. What we have is a very clever hack by Chuck Lane that implements pipes using mailboxes, QIOs, ASTs, and other VMS goodies. There are two main problems I'm aware of. One is that mailboxes are inherently record-oriented devices, and pipes need to be stream-oriented. You can fake stream-orientedness to a large extent with buffering, but you will always get the occasional record boundary inserted in your stream, especially if you are aggressively flushing every I/O to make sure the other process doesn't get hung up waiting for you. Unexpected spurious line breaks are the single most common cause of test failures in the development releases of Perl because the test suite uses pipes so heavily. The other main problem with Chuck's implementation is that it uses DCL to reassign process-permanent files (the PPFs are SYS$INPUT, SYS$OUTPUT, and SYS$COMMAND). Though I know of no easy alternative, DCL just doesn't seem like the right tool for the job here, and may even be susceptible race conditions in a multi-threaded environment. The CRTL piping implementation that Chuck's version replaces is susceptible to all sorts of hangs and race conditions. I gather that it was never intended to work apart from the now-long-defunct POSIX subsystem. It too is based on mailboxes. It may have improved in the v7.3-x era, but I can't find anything in the release notes indicating as much. I think the first thing that needs to be done is make the homegrown pipe implementation a configure-time option. That way if the CRTL version ever gets good enough, we can simply flip the switch and start using it. It also opens up the possibility for scrounging or building other implementations (anyone got the sources and want to have a crack at using SYS$PIPEDRIVER?). The way to do this would be to start in safe_popen() in [.vms]vms.c and follow the trail. 2.) New and/or improved system() and backticks implementation. There's been some traffic on the list in recent months about limitations in spawning subprocesses. The ones I remember are that because we are using lib$spawn, command length is limited to the DCL command buffer's 255 characters, and if we are running under bash, we ought to run the subprocess under bash rather than DCL. Suggestions were made that we delve into GNV's bash implementation and see how subprocesses are handled there. Cautionary messages were posted about not breaking existing semantics. 3.) ODS-5 filename support. This actually includes a number of different features; we need all of them but they could be implemented independently. A partial list includes handling mixed-case names, names with multiple dots, names with non-ASCII characters, and names longer that 255 characters. John Malmberg got us pretty far along with the C parts of this. There will also need to be some changes to File::Spec and ExtUtils::MakeMaker, some of which have been discussed quite a bit on the list before. Something I'll also mention here that John Malmberg told me about off list. We have a lot of automatic variables that are used for temporary filename storage; if we switch the lengths on them al from NAM$C_MAXRSS to NAML$C_MAXRSS (255 --> 4095), we will probably, based on John's experience with other packages, blow up the stack on a regular basis. We'd also have to switch them to malloced storage instead of stack variables. 4.) Support for the C++ compiler. A couple of years ago, Peter Prymmer started adding support so that folks who only have the C++ compiler can build Perl. I'm not sure how far we are from being finished with this, but it would be nice to have. There are some extensions that require C++, so it would help in those cases too. This probably involves additional changes to configure.com and perhaps ExtUtils::MakeMaker. 5.) Evaluate building with Configure under GNV rather than configure.com under DCL. Though the GNV project seems to have painfully slow progress and at this point is also painfully incomplete (compare to Cygwin, for example), it should eventually be possible to switch to using the Configure shell script to configure a Perl build and avoid further maintenance of the 6600-line DCL procedure configure.com. I have feeling we are some ways away from this, but it seems worth mentioning as a future direction. 6.) Evaluate porting the pthread-based Win32 pseudo-fork. Activestate, with some funding from Microsoft, implemented a fork() lookalike based on POSIX threads for their Win32 Perl product a few years ago. There's no particular reason this shouldn't work on VMS, though we'd very likely expose and have to fix some latent bugs in the process. We'd also have to modify some of the functions that operate on processes to make them operate on pseudo-processes implemented as threads. See [.pod]perlfork.pod. 7.) Signal handling improvements and fixes. We currently check at configure-time to see if the CRTL can call kill() from within a signal handler, something that the Perl test suite explicitly requires and checks for. If it can, we use the CRTL's signals. Unfortunately, no version of the CRTL in the wild at this moment works properly in this regard, so we always use a homegrown replacement based on the undocumented system service sys$sigprc. This works fine on Alpha and VAX, but we currently have a hard-wired and very out-of-date list of signals that we'll support; we need to upgrade this list. The other problem is that the sys$sigprc implementation doesn't work in OpenVMS I64 v8.1. Probably the best thing is to wait for v8.2 and see if it works there before doing anything drastic, but it's possible our current workaround is nearing the end of the line. 8.) Port Test::Smoke to VMS. The Test::Smoke module is used to automatically churn through various configurations of the latest development snapshot of Perl and report failures to a mailing list monitored by the perl QA folks. If we got this working (both the module and a machine or two to run it on), anyone making changes to Perl would know instantly whether it broke something on VMS. They might not know how to fix it, and would pester us for help with that, but at least there would be less archive diving to figure out what broke when, plus we'd have more thorough testing than we typically get from my manual tests. 9.) Enable support for new CRTL functions in VMS 7.3-x. The version dependency tables in the CRTL manual show 5 new functions for v7.3, 19 new functions for v7.3-1, and 47 new functions for v7.3-2. Some of these, such as nanosleep() and poll(), we've added support for, but we really need to do a thorough review to see if there's anything there we should be using but aren't. 10.) Support ODS-5's POSIX volume characteristics (e.g. access dates). We should look at our utime() and stat() implementations (and perhaps others?) and do what the CRTL does when there are extended volume characteristics available. Comments, questions, and especially volunteers are all welcome. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
