⎕FSTIE has different behavior compared to Windows

Using Dyalog under 'nixes

⎕FSTIE has different behavior compared to Windows

Postby harsman on Tue Aug 17, 2010 12:05 pm

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.
harsman
 
Posts: 27
Joined: Thu Nov 26, 2009 12:21 pm

Re: ⎕FSTIE has different behavior compared to Windows

Postby AndyS|Dyalog on Tue Aug 24, 2010 3:10 pm

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.
User avatar
AndyS|Dyalog
 
Posts: 220
Joined: Tue May 12, 2009 6:06 pm

Re: ⎕FSTIE has different behavior compared to Windows

Postby harsman on Wed Aug 25, 2010 8:52 am

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?
harsman
 
Posts: 27
Joined: Thu Nov 26, 2009 12:21 pm

Re: ⎕FSTIE has different behavior compared to Windows

Postby Morten|Dyalog on Thu Aug 26, 2010 8:29 am

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.
User avatar
Morten|Dyalog
 
Posts: 356
Joined: Tue Sep 09, 2008 3:52 pm

Re: ⎕FSTIE has different behavior compared to Windows

Postby harsman on Thu Aug 26, 2010 5:33 pm

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

Postby Morten|Dyalog on Thu Aug 26, 2010 8:16 pm

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.
User avatar
Morten|Dyalog
 
Posts: 356
Joined: Tue Sep 09, 2008 3:52 pm


Return to UNIX and Linux

Who is online

Users browsing this forum: No registered users and 1 guest