Mapped files are for specific purposes. They have some drawbacks over normal
J nouns. And they have some advantages. Mapped files are not a replacement
for nouns. Mapped files are a direct and efficient mapping of J (through
nouns) onto underlying OS and hardware services. If you want the behavior of
normal nouns then use normal nouns. If you want the behavior of mapped files
then use mapped files.
----- Original Message -----
From: "Don Guinn" <[EMAIL PROTECTED]>
To: "Programming forum" <[email protected]>
Sent: Sunday, April 01, 2007 2:38 PM
Subject: Re: [Jprogramming] readonly mapped files
Soap box time!
I should have complained when mapped files was first being implemented;
however, I wasn't sure about my thoughts at the time. Now I feel that one
developing a utility tool should not have to consider the possibility that
a
name passed to it might refer to a mapped file. It should be the other way
around. One dealing with mapped files should be the one to consider the
implications of passing a mapped name to a utility might cause problems.
As I mentioned in my previous post, there are traps all over the supplied
J
libraries and tools supplied by others that will corrupt a mapped file if
one isn't careful when working with mapped files. Making the file
read-only
really helps but while one resets read-only to modify the file the traps
are
exposed. Resetting and setting back "read-only" is not neat. When a name
is
assigned to a mapped name it can still refer to the same memory as the
mapped name but treated like the sharing of memory for for multiple
non-mapped names. That is, if the second name is modified it is given its
own memory so the original name is not affected. OK, as mentioned in the
tutorial, if somebody maps a huge file to a name and a local name
referring
to its memory gets modified and J gives an out of memory, but how is that
different than having the same error with non-mapped names? An error is an
error. Mapped files are great for extremely large files where this could
be
a consideration but they are quite useful for small files as well for
inter-process communication.
There are times where one needs to modify the contents from a mapped name
without affecting the mapped file. It is not clear what one should do to
assure that the contents of a mapped name can be referenced by another
name
in such a manner that the contents of the second name can be modified
without affecting the original mapped file. Nothing in the lab addresses
that issue. Is it sufficient to put "[" in front of the mapped name to
make
it a copy? if not, what is? Just trying things to see if they work is
risky
as a future release of J may change that. Even an index or a substring
reference might refer into the middle of the contents of another name
which
could be to a mapped file in a future release of J.
Another issue, when I first heard about mapped files I thought of shared
variables in APL. I always loved them and as shared variables provided,
giving a standard way to notify other J sessions sharing a mapped file
that
it is being modified would make mapped files much more useful. A session
has
to periodically check the contents of a mapped file to see if it has
changed. It reminds me of a kid in the back seat asking, "Are we there
yet?"
Or, as mentioned in the lab, one can use some other mechanism such as
mutex
or semaphore when the mapped file changes. This would be extensive work as
other sessions would have to be identified and mechanisms built to send
and
receive such messages.
This seems silly when it would be so easy for J copula processing to
handle
notification when it is to a mapped name. When a J instance modifies a
mapped file it could set a flag in the file control block that the file
has
been modified and possibly cause an event to the triggered in other
sessions referring to the mapped file. Everyone could handle this the same
way as it would be part of J. That could be quite useful. Granted, non-J
applications could still modify a mapped file and not notify any J session
using the mapped file. However, a call could be made available that a C
program or whatever could use to provide the notification. That's just
moving the notification of a change into J copula processing.
On 4/1/07, Eric Iverson <[EMAIL PROTECTED]> wrote:
This issue was discussed a bit back in August. A readonly verb in the jmf
script allows toggling the readonly state of a mapping. Please study the
copied messages below. This is also covered in the lab. I think this is
an
adequate solution to the problem. If it isn't please clarify.
Map your files as readonly and toggle them carefully as required for
updates.
***
>Eric Iverson to Beta forum August-31-06
. . .
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
