named reconfig bug???

[Cody.Gibson at intermec.com]

In testing my port of BIND8 to OS/2, I discovered that frequently a "ndc
reconfig" would cause named to abort and log this in the system log:

12/06/99 14:40:18 CRITICAL  : ..\..\..\bin\named\ns_main.c:539: INSIST(errno
== EINTR || errno == EWOULDBLOCK): The file or directory specified cannot be
found. failed.

In tracking down the source of this I found that ERRNO == ENOENT at the time
of failure. It's being set to ENOENT every single time during the reconfig
process. Here's what happens:

1) update_pid_file() deletes the .PID file that currently exists with this
code:
	if (current_pid_filename != NULL) {
		(void)unlink(current_pid_filename);
		freestr(current_pid_filename);
		current_pid_filename = NULL;
	}
2) update_pid_file() calls write_open() to create a new one.
3) The first thing that write_open() does is a stat() on the file name with
this code:
	if (stat(filename, &sb) < 0) {
		if (errno != ENOENT) {
			ns_error(ns_log_os,
				 "write_open: stat of %s failed: %s",
				 filename, strerror(errno));
			return (NULL);
		}
4) ERRNO is now set to ENOENT and remains there for the remainder of the
reconfig process.
5) handle_need() returns to the main loop leaving ERRNO == ENOENT.
6) IF there happens to be another need set, the main loop fails in this
code:
		if (needs != 0) {
			/* Drain outstanding events; handlers ~block~. */
			while (evGetNext(ev, &event, EV_POLL) != -1)
				INSIST_ERR(evDispatch(ev, event) != -1);
			INSIST_ERR(errno == EINTR || errno == EWOULDBLOCK);

Have I found a new bug? Is OS/2 doing something radically different then all
the other ports that exist? Before I attempt to fix this, I need some
feedback on how it works/doesn't work on other ports.

Thanks for your help,
Cody Gibson
Software Developer
Intermec Technologies Corporation