⎕FSTIE has different behavior compared to Windows
6 posts
• Page 1 of 1
⎕FSTIE has different behavior compared to Windows
Under Windows, it's perfectly fine to tie the same file several times from the same process with ⎕FSTIE:
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.
- 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.
- harsman
- Posts: 27
- Joined: Thu Nov 26, 2009 12:21 pm
Re: ⎕FSTIE has different behavior compared to Windows
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.
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.
-
AndyS|Dyalog - Posts: 263
- Joined: Tue May 12, 2009 6:06 pm
Re: ⎕FSTIE has different behavior compared to Windows
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?
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?
- harsman
- Posts: 27
- Joined: Thu Nov 26, 2009 12:21 pm
Re: ⎕FSTIE has different behavior compared to Windows
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.
-
Morten|Dyalog - Posts: 460
- Joined: Tue Sep 09, 2008 3:52 pm
Re: ⎕FSTIE has different behavior compared to Windows
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.
- harsman
- Posts: 27
- Joined: Thu Nov 26, 2009 12:21 pm
Re: ⎕FSTIE has different behavior compared to Windows
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.
-
Morten|Dyalog - Posts: 460
- Joined: Tue Sep 09, 2008 3:52 pm
6 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group