From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 18:49:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930F310656A3; Fri, 22 Jan 2010 18:49:58 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 204FB8FC23; Fri, 22 Jan 2010 18:49:58 +0000 (UTC) Received: from [32.177.153.43] ([32.177.153.43]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MInqKA001502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 13:49:55 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <72CD3F66-1428-4876-BE35-6651417C5BC0@lakerest.net> From: Randall Stewart To: Daniel Eischen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 10:49:44 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> <20100122172525.GA37884@stack.nl> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@freebsd.org, Ivan Voras , Jilles Tjoelker Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:49:58 -0000 Daniel: Well it may be ugly, but it gets even uglier on how you have to pass the mtx down to the kernel with the cond wait variables... One can do it.. but it will take some additional changes to the kevent structure which breaks the ABI... which I was not going to venture down that path :-) Hmm I suppose one might be able to abuse udata. Right now the incoming "value" is in the data (the value that is checked before putting you on the umtx sleep queue). We could, pass the mtx into the "udata" field but this rather breaks the definition of udata: "Opaque user-defined value passed through the kernel unchanged" Now I suppose if you placed the MTX pointer there that you are NOT exactly changing it ... but you WOULD be changing the value of it (as you unlock the mutex).. I will work on getting this first set of changes into the kernel. If we don't abuse udata, then the only choice would be to add some additional "data" element.. or maybe as Ivan suggested a "blob" which would still mean an ABI change since you would have to include a size in the blob... hmmm unless we did "data" is a pointer and flags is the size.. But this really seems hackish .. sigh .. R On Jan 22, 2010, at 9:58 AM, Daniel Eischen wrote: >> > > This is ugly from the userland point of view -- if you need > this, I would encompass everything in a kq event object > thingie. As in: > > /* > * Create an object containing everything you need to wait > * or signal kqueue events. > */ > kq = kqueue(); > kq_obj = kq_create(kq, ...); > > kq_lock(&kq_obj); > while (!P) > { > /* Atomically unlocks kq_obj and blocks. */ > nevents = kq_wait(&kq_obj, ...); > > /* When you wakeup, kq_obj is locked again. */ > } > > do_work(); /* Wouldn't you want to unlock before this? */ > kq_unlock(&kq_obj); > > > /* From another thread, you could do: */ > kq_lock(&kq_obj); > if (kq_waiters(&kq_obj) > 0) > kq_signal(&kq_obj); /* or kq_broadcast() */ > kq_unlock(&kq_obj); > > > -- > DE > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)