At 07:33 PM 10/30/00 -0600, Craig A. Berry wrote:
<Snipped>
>Thanks for the tip; I'll try to take a look at Storable and see if
>omitting locking seems like the right thing to do for VMS.
Well, the changes I contributed to Storable don't *eliminate* locking,
they just change Storable to Carp about it if you try to use
"lock_store" or "lock_retrieve", and then return "undef". The "lock"
tests are just bypassed if ($^O eq 'dos'), with a message about broken
fcntl/flock on our platform.
The rest of Storable was unchanged.
>My punishment for not getting a patch out yet is having to explain
>again how all this works on VMS. There's no flock() at all, nor, I
>believe lockf(). It usually doesn't matter because files are locked
>by default; if you want shared access you have specify it explicitly.
>fcntl() exists on some versions of the C RTL from the last two years
>or so, but it doesn't do F_SETLK/W. It does have those defined in
>the header, but it doesn't do anything with them, thus fooling the
>test for them in pp_sys.c where it tries to see if fcntl() can
>emulate flock(). We should probably have something in configure.com
>that checks to see if (when fcntl exists) F_SETLK and F_SETLKW
>actually work and undef's them if not; this would make the test in
>pp_sys.c realize that fcntl() cannot emulate flock().
Yes, but what will Configure do when it discovers it has no "flock" and
no way to emulate it at all? Does it barf?
BTW, sorry for replying to Peter P. before I read your $0.02
worth. Just ignore the useless stuff about "lockf" in my reply to him.
>BTW, I get "All tests successful" with perl@7483 using DEC C V5.2-003
>on OpenVMS Alpha V7.1. I do notice, however, that with perl -V its
>identity lags slightly behind:
>
> Locally applied patches:
> DEVEL7481
Yes, I noticed the same thing on DJGPP, but since I'm so new here, I
assumed it was normal. Isn't it?
---------------------------------------------------------
Peter J. Farley III ([EMAIL PROTECTED] OR
[EMAIL PROTECTED])
