Date: Mon, 21 Mar 2005 10:16:26 -0500 From: Stephan Uphoff <ups@tree.com> To: matthew@digitalstratum.com Cc: Zera William Holladay <zholla1@uic.edu> Subject: Re: Causing a process switch to test a theory. Message-ID: <1111418186.29804.130653.camel@palm> In-Reply-To: <423ED74C.1050705@digitalstratum.com> References: <423DE326.9000203@digitalstratum.com> <Pine.GSO.4.58.0503202314100.3910@icarus.cc.uic.edu> <423ED74C.1050705@digitalstratum.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-03-21 at 09:16, Matthew Hagerty wrote: > Zera William Holladay wrote: > > >If you post the section(s) of code in question, then you'll probably > >elicit some responses. PIPE_BUF is a POSIX defined minimum, so you might > >grep for sections of code that contain fpathconf(*, _PC_PIPE_BUF) to > >determine if the programmers took this into consideration. At least > >you'll be able to follow the logical flow of the program from fpathconf() > >forward. > > > >Further, if you do some fancy programming (like preempting a process > >unnaturally) to determine if there is an error in this particular aspect > >of Apache, then you'll also have to show that you have not inflicted the > >error too, which will probably be harder than what you set out to solve or > >figure out. > > > >Good luck, Zera Holladay > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > > > I was not wanting to preempt any of the processes unnaturally, I was > looking more for suggestions as to how I can reliably cause preemption > for testing. Without knowing the details of how FreeBSD's scheduler > works, I could only assume that making a heavy load might cause such > preemption to happen, but that is just an under educated guess. > > I'm not familiar with fpathconf(), I'll go look that up for sure and > check Apache's code for it's use. Thanks! > > As for code, below is the portion that does to actual writing to the log > file, opened as either a normal file or a pipe depending on the config > file. Also note that BUFFERED_LOGS is not normally defined (must be > passed to make at compile time), and even then it only makes sure there > is *at least* LOG_BUFSIZE bytes to write before writing. It does not > prevent longer than LOG_BUFSIZE bytes from being written. > > Matthew > > < SNIP -- CODE DELETED > Why not just replace the write() call with a small test function? There is really no need to modify the kernel for your experiments. size_t test_pipe_write(int d, const void *buf, size_t nbytes) { size_t n; size_t done=0; while (nbytes > ATOMIC_WRITE_MAX) { n = write(d,buf,ATOMIC_WRITE_MAX); if (n <= 0) return done; buf = (char *) buf + n; nbytes -= n; usleep(NAP_TIME); } n = write(d,buf,nbytes); if (n <= 0) return done; else return n + done; } Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1111418186.29804.130653.camel>