Date: Tue, 7 Jan 1997 20:45:50 -0400 (AST) From: The Hermit Hacker <scrappy@hub.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@FreeBSD.ORG Subject: Re: mmap() updates...how often? Message-ID: <Pine.BSF.3.95.970107202912.3629I-100000@thelab.hub.org> In-Reply-To: <199701080006.RAA15234@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Jan 1997, Terry Lambert wrote: > If it's MAP_SHARED, then it is updated instantaneously... that is, > it's the same physical memory mapped into both processes. > Okay, that is how its MAP'd...so that isn't my problem... > The context switch rate for a compute intensive task is 100HZ or > once every 10ms. Most likely, the client isn't getting a chance to > run, and the server is monopolizing the CPU. > This sounds reasonable... > > Not being quite sure of what other data I can provide, does > > anyone have any suggestions on what I'm seeing? Since its memory > > mapped, I would have made the assumption that changes to the data > > would be seen instantaneously by the client, but either I'm missing > > something in my code (staring at it too long does that) or I'm once > > more missing something with mmap() > > How are you making sure that the server does not reuse the memory > region before the client displays it? > This is currently the problem I'm looking at fixing... I'm going through the various "solutions" addressed in "Advanced Programming in the Unix Environment" by Stevens, but so far haven't found something that "sounds" reasonable. Its a one->many setup, with many being anywhere from 1 to 1000, at any one time. Semaphores, from what little I understand of them, won't cut it, because I'll have to go through hoops to make sure that each of the clients gets registered with the server, and then de-registered once they go away. Unfortunately, my understanding of them is *very* weak until I've actually programmed them (chicken before egg dilemna *sigh*)... The one thing I was thinking of was to create a socket-based ctl channel. So, when the server has written the frame to memory, it loops through the client sockets, sending it a control message. Then, once that is done, it can go to the next frame. The problem with that is that the server is currently able to write 20+frames/sec to the MMAP'd region...what sort of slowdown can I expect if I have 1000 open sockets that each have to have that control data written to, sequentially? Oh well... I'm still looking for solutions, so if anyone has a path that they think I should research further (ie. am I mistake about semaphores?), please let me know...am all ears... > If the client is an X client, are you using "XSync( Xdisplay);" to > make sure the X servr is not "optimizing" away your screen updates? > No, not using X at all...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970107202912.3629I-100000>