ETXTBSY

[Jean-Pierre A. Radley]

>From a SCO engineer:

| While I'm sympathetic and would also like to hear what the issues
| are, I don't think this is likely to change.  This behavior has been
| in Solaris, SunOS, and Unix System V for over 15 years, with lots of
| systems and customers running just fine.
|
| There is an indivisible diamond here, which is the VM architecture
| in System V Release 4, UW7, OSR6, Solaris, etc.  It has many, many
| advantages over the previous VM design - performance, reliability,
| scalability, ease of maintenance, extensibility, and so forth.  It's a
| significant upgrade over earlier systems in and of itself, and it's an
| enabler of many of the other technology upgrades that come along with
| it.

| However, like all diamonds, it has flaws.  ETXTBSY is no longer
| supported.  This is pretty much a result of one of the key aspects
| of the VM design, which is that there is only one copy of a given
| file page in the system for all uses.  Thus, any attempt to put back
| ETXTBSY is going to be so expensive that it's not going to be worth
| it unless there is some huge revenue opportunity that is going to be
| lost simply because ETXTBSY is not supported.  This seems an unlikely
| scenario.
|
| Now, how serious a flaw is the lack of ETXTBSY compared with the
| advantages of the new design over the old?  Frankly, it seems very
| minor.  Yes, it's annoying at first, and it takes some getting used
| to, but once you get burned once or twice, you learn to work with it.

| As I say, I'm sympathetic.  I remember when this was introduced, and
| there were a number of AT&T engineers who were unhappy with this
| change, but it was accepted as a cost of moving forward.  It still
| seems like the right tradeoff.


Have a look at
	www.caldera.com/support/docs/openserver/600/porting/osr6porting.pdf.
ETXTBSY comes up in Section2.

-- 
JP