Date: Mon, 11 Nov 1996 16:12:14 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: terry@lambert.org (Terry Lambert) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, scrappy@ki.net, twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org Subject: Re: semaphores/shared memory Message-ID: <199611112212.QAA19941@brasil.moneng.mei.com> In-Reply-To: <199611112003.NAA18571@phaeton.artisoft.com> from "Terry Lambert" at Nov 11, 96 01:03:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > However, now I have to question my assumptions... why is it necessary > > > for the clients to signal the server? > > > > Reuse of the buffer area? > > > > It would be stupid for the server to start writing new data before > > everyone else is done with it. > > If 99/100 of the clients succeed, we should hang the other 99 for the > one that is lagging out? I guess that depends on the application. :-) I was not going to try to dictate to someone else how to write a UNIX multi process application, he already has the Stevens book. > It would be useful to know if the data stream can be resynchronized, > and what the actual effect of data loss for one client would be. > > Also, the effect would be negligible if you double-buffered the > client buffer area. If the discrete buffer areas were large enough > that the buffer could contain all the data sent in the maximum pool > retention time window, then it would not be a problem. Sure.. and sure again. The question did not indicate that the data was not already being double (or multi) buffered. You would still need to signal completion and acknowledgement on a per-buffer basis... same question, basically. :-) OTOH, a description of the problem being solved may not be a bad idea. It will then let us make valid guesses as to how the process might be improved... ;-) ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611112212.QAA19941>