Subject | Engineering project description |
---|---|
Author | Ann Harrison |
Post date | 2000-05-16T17:03:38Z |
I'd like to describe a late change that is being introduced
into V6 and the way decisions were made about the necessity
and the architecture of the change. This time, the discussion
was face-to-face in the InterBase engineering group. When
InterBase is open source, this process will occur on the
developers' list.
An InterBase VAR called because a customer had gone live with
an application and had got an error (fopen failed) with about
249 clients connected to the database. The platform was Solaris
and the customer estimated that the max load would be about
400 clients at a time.
Identifying the problem was reasonably simple*. Solaris uses
a byte in its file descriptor where a word or a long word
would be better. The descriptor is used only for buffered
I/O, but it shares a number space with connected sockets.
The socket identifiers can go higher in the number space, but
numbers are allocated smallest first, and reused. Once the
first 255 numbers are used, all fopen calls fail. This is
a well-known characteristic of Solaris.
Interbase uses buffered file I/O for writing the log file,
for reading hosts.equiv and the password file, for debugging
messages, and for external tables.
We considered declaring this an operating system problem or
an application design problem. Neither solved anyone's
problems. SUN isn't about to change their operating system
and the customer's application design ... well there was
resistance to change. Nor could the problem be delayed
to a later release.
We considered performing all the fopen's at server startup
so those files would be guaranteed low numbers. Debugging
printf's might fail, but how often does one debug with
250 clients attached? However, changing the timing of
file opens involved more code changes than seemed prudent
at this stage of the project and having external tables fail
randomly was not acceptable.
Our Unix guru mentioned that the BSD stdio routines have a
compatible license, work on Solaris, and eliminate the problem.
The question was how to integrate them with our code. There,
the goals were:
Keeping the code maintainable - meaning that things should be
what they seem to be - so we would not change "fopen" to a
macro that expands differently on Solaris than other platforms.
Keeping the change simple. That ruled out writing our own
buffered file I/O or changing to open/read/write generally.
Minimizing in-line ifdefs.
The solution we chose was to replace all references to stdio.h
with ib_stdio.h, and all buffered functions from <func> to
ib_<func>. Those changes are pervasive but mechanical. Ib_stdio.h
will define the ib_<func>s as macros that expand into the normal
stdio calls & macros on most systems, and macros & calls to the BSD
equivalents (renamed) on Solaris. We will consolidate the BSD stdio
routines into a single module and include it in our Solaris builds.
Ann
Ann
* Well, simple if you have Unix guru's on staff.
into V6 and the way decisions were made about the necessity
and the architecture of the change. This time, the discussion
was face-to-face in the InterBase engineering group. When
InterBase is open source, this process will occur on the
developers' list.
An InterBase VAR called because a customer had gone live with
an application and had got an error (fopen failed) with about
249 clients connected to the database. The platform was Solaris
and the customer estimated that the max load would be about
400 clients at a time.
Identifying the problem was reasonably simple*. Solaris uses
a byte in its file descriptor where a word or a long word
would be better. The descriptor is used only for buffered
I/O, but it shares a number space with connected sockets.
The socket identifiers can go higher in the number space, but
numbers are allocated smallest first, and reused. Once the
first 255 numbers are used, all fopen calls fail. This is
a well-known characteristic of Solaris.
Interbase uses buffered file I/O for writing the log file,
for reading hosts.equiv and the password file, for debugging
messages, and for external tables.
We considered declaring this an operating system problem or
an application design problem. Neither solved anyone's
problems. SUN isn't about to change their operating system
and the customer's application design ... well there was
resistance to change. Nor could the problem be delayed
to a later release.
We considered performing all the fopen's at server startup
so those files would be guaranteed low numbers. Debugging
printf's might fail, but how often does one debug with
250 clients attached? However, changing the timing of
file opens involved more code changes than seemed prudent
at this stage of the project and having external tables fail
randomly was not acceptable.
Our Unix guru mentioned that the BSD stdio routines have a
compatible license, work on Solaris, and eliminate the problem.
The question was how to integrate them with our code. There,
the goals were:
Keeping the code maintainable - meaning that things should be
what they seem to be - so we would not change "fopen" to a
macro that expands differently on Solaris than other platforms.
Keeping the change simple. That ruled out writing our own
buffered file I/O or changing to open/read/write generally.
Minimizing in-line ifdefs.
The solution we chose was to replace all references to stdio.h
with ib_stdio.h, and all buffered functions from <func> to
ib_<func>. Those changes are pervasive but mechanical. Ib_stdio.h
will define the ib_<func>s as macros that expand into the normal
stdio calls & macros on most systems, and macros & calls to the BSD
equivalents (renamed) on Solaris. We will consolidate the BSD stdio
routines into a single module and include it in our Solaris builds.
Ann
Ann
* Well, simple if you have Unix guru's on staff.