[comp.sys.sun] Too many paranoids!

ken@uunet.uu.net (Ken Hardy) (06/05/91)

I've got a SunView application (sorry, it just won't go away) that
causes two errors repeatedly:

	Notifier error: Too many paranoids using enumerator
and
	Notifier error: Invalid argument

I suspect that the first one is from use of proscribed system calls,
ioctls, and/or signals.  They seem to have lessened after finding an
illegal call to setitimer(2).

What _exactly_ does "too many paranoids ..." mean???  I suspect it has
to do with SV's replacement of certain I/O system calls as a chance to
do its own thing.  BTW, I'm using implicit event dispatching, as set up
by the notify_do_dispatch() call.

Does anyone have a good method of debugging these things?  How can I
tell where in my code the errors are being triggered?  What's the
invalid arguement?  Such verbosity in error messages is practically
underwhelming!

The SunView code I support is in the form of a library used by a suite
of applications programs that are platform/environment independent.  We
have our own API to which the apps are coded.  My code provides that
API to the applications using SunView.  (Similar libraries allow the
same applications to run under DOS, Windows 3.0, OS/2's PM, and X.)

The errors apparently are caused by code in one of the applications.
It had worked (practically) flawlessly.  Then we created the X interface
library and ignored SunView for quite some time.  Now our sole, but
important, SunView customer needs to be upgraded to the latest release
of the applications.  Remaking the applications with the SunView
libraries causes the notifier errors.  The applications have undergone
considerable modification since last linked with the SunView
interface.

It might be a lot easier to correct the problem if I knew what a
(SunView) paranoid is.  And a lot easier still if someone has some
specific debugging hints.  ["Paranoids" and "enumerators" are not
mentioned, that I can find, in my Sun documents.]

I am running SunOs 4.0.x on Sparcs and 386i's.


-- 

Ken Hardy                         uunet!racerx!ken
Bridge Information Systems        racerx!ken@uunet.uu.net