Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!sgiblab!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!lopez!scott Newsgroups: comp.unix.bsd Subject: [386BSD] FIFO support: an update From: scott@lopez.marquette.MI.US (Scott Reynolds,Insanity) Message-ID: <pmOme-to0@lopez.marquette.MI.US> Date: Wed, 30 Sep 1992 09:33:41 EDT Organization: Great White North/UPLink Lines: 46 I've narrowed it down a bit further. In kern/fifo_vnops.c I added a printf() to check what the number of readers and writers on the fifo was (and the address of the fifo structure to make sure I'm looking at the same one). The result of this was that the first open (for reading) proceeds normally: create the fifo structure tack it onto the vnode setting up the sockets zeroing out the count of readers and writers ===[ above this line executes only on creation of fifo ]=== printf() -> "addr = xxxx, readers = 0, writers = 0" increment number of readers tsleep() waiting for writers to start up The second open, for writing, goes like this: printf() -> "addr = xxxx, readers = 0, writers = 0" !! increment number of writers tsleep() waiting for readers to start up The "addr = xxxx" varies between tests but always agrees on any given trial. The surprising part is that the number of readers and writers is always 0! Some experimenting proved that setting the number of readers and writers to 1 in the structure init will give a "working" fifo, but the problems associated with this hack in the real world are obvious. [In case you're wondering, the printf() always prints "readers = 1, writers = 1" when I do this.] How can this happen? The way I understand it, kernal malloc() returns memory for use by the kernal and not the user process, and memory obtained in this way is semi-permanent in the sense that it stays around as long as the kernal needs it and it doesn't have any relationship to the user process that made the call. This is supported by the evidence I've accumulated, also (I put a printf() inside the fifo creation code at one point). I'm baffled. Nothing in this code appears to be incredibly complex yet it has defied my best efforts to track down the problem. Suggestions? Comments? Please let me know, even if you think it's obvious and I haven't mentioned it here. -- Scott Reynolds scott@lopez.marquette.MI.US Great White North/UPLink alternate: A094@NMUMUS.BITNET "Insufficient facts always invite danger." -- Spock