Date: Fri, 31 Jan 97 15:27:13 +0000 From: Andrew.Gordon@net-tel.co.uk To: "Ron G. Minnich" <rminnich@Sarnoff.COM> Cc: freebsd-hackers@freebsd.org Subject: Re(2): Re(2): Using rfork() / threads Message-ID: <"5fb2-970131152702-FFD1*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> In-Reply-To: <Pine.SUN.3.91.970131093856.16303C-100000@terra>
next in thread | previous in thread | raw e-mail | index | archive | help
> well, i have another thing that was (ah well) offered to freebsd called > fastlock(). Fastlock was two things: > 1) test and set, which ran at memory bandwidth > 2) a system call to be called only if the lock failed, > which ran at system call speeds. Sounds just the ticket for what I need. I am quite often writing servers for one network protocol or another, where the the server holds per-user state for a large number of users, but the users typically spend much of their time asleep at the keyboard and hence a process-per-user design is wasteful, but in the absence of async I/O, a one-process design has insufficient parallelism. The ideal compromise is a small number of processes picking work off a queue - but this needs the per-user state to be shared between the processes and a means of sharing out the requests. You can do some of this with SysV SHM and semaphores, but it gets inefficient when one of the pieces of per-user state you would like to share is an open fd. rfork() and fastlock() seems a much more efficient combination, though there is a potential problem with running out of fds in a large system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"5fb2-970131152702-FFD1*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">