⎕FSTIE has different behavior compared to Windows

[harsman]

Under Windows, it's perfectly fine to tie the same file several times from the same process with ⎕FSTIE:

Code: Select all

tie1←'myfile'⎕FSTIE 0
tie2←'myfile'⎕FSTIE 0

But the second line will get a FILE TIED error when running on AIX (I haven't tested Linux yet). If I start two APL processes, they can both ⎕FSTIE the same file (that's the whole point of ⎕FSTIE after all). So why the restriction within the same process? Is this a bug or a feature? It isn't documented as far as I can tell.

I've tested both 12.1 and 10.0, they behave the same.

[AndyS|Dyalog]

Historically this was the result of being unable to be sure that under Windows two different references to the same file actually refered to the same file. So Dyalog APL allowed the same file to be ⎕FSTIEd multiple times on that platform.

It is more likely that in the future we will remove this capability from the Windows versions, rather than add the capability to the UNIX versions, since it is seen as a potential stumbling block blocking the way to allowing component file access to become more multi-threaded - for example, to allow other APL threads to continue while other threads are blocked on I/O access.

[harsman]

Oh, ok so you check the inode number to make sure you don't get duplicate ties?

Not being able to ⎕FSTIE the same file twice in the same process is a bit of a bother because it makes running certain tests related to race conditions and component files very hard. It would be nice if I didn't need to write an entire multiprocess framework just to run tests.

Just out of curiosity, how does this make not blocking on IO harder? Does async/evented IO have restrictions on using different fds for the same file?

[Morten|Dyalog]

What sort of race condition tests are you running? If we allowed multiple ties, some race condition tests would be invalid within the context of a single process. For example, ⎕FHOLD becomes fairly meaningless as it always starts by releasing any existing holds.

[harsman]

That's exactly the case I want to test! Basically I am testing some storage middleware to ensure that if a hold has been released and someone calls hold again, some internal transaction counters get updated. It's not critical or anything, just a minor annoyance and I couldn't understand the point of not allowing to tie the same file twice.

[Morten|Dyalog]

In that case, I think your tests will be equally valid if you just tie the file once. Even if you got a second tie number, it would be the same file from a locking point of view - or so I believe.