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
