RE: select(2) converted to use a condition variable, and optimis

2001-05-15 Thread Seigo Tanimura
On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura tanimura said: Seigo On Tue, 08 May 2001 08:21:55 -0700 (PDT), Seigo John Baldwin [EMAIL PROTECTED] said: John On 08-May-01 Seigo Tanimura wrote: Here is another issue. PROC_LOCK may block to acquire a process lock, during which an event

atomic operation of flags (was: RE: select(2) converted to use a condition variable, and optimis)

2001-05-14 Thread Seigo Tanimura
On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John You need the lock when clearing the bit in p_flag. That is why the proc locks John are there, so all those proc locks need to stay. When you clear a bit, you are John writing all the bits, so you need to

Re: select(2) converted to use a condition variable, and optimis

2001-05-11 Thread Seigo Tanimura
On Thu, 10 May 2001 09:06:15 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo A quick and hopefully efficient solution to those problems is to Seigo fhold() struct file's first, then enter polling loop. That seems much Seigo cheaper than to work on free()ing a vnode or a socket with holding

Re: select(2) converted to use a condition variable, and optimis

2001-05-10 Thread Terry Lambert
Seigo Tanimura wrote: A quick and hopefully efficient solution to those problems is to fhold() struct file's first, then enter polling loop. That seems much cheaper than to work on free()ing a vnode or a socket with holding a process lock, provided that struct filedesc and file are protected

Re: select(2) converted to use a condition variable, and optimis

2001-05-10 Thread John Baldwin
On 10-May-01 Terry Lambert wrote: Seigo Tanimura wrote: A quick and hopefully efficient solution to those problems is to fhold() struct file's first, then enter polling loop. That seems much cheaper than to work on free()ing a vnode or a socket with holding a process lock, provided that

RE: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread Seigo Tanimura
On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura tanimura said: Seigo That does not, however, necessarily imply that we can scan file Seigo descriptors with holding a process lock. Another process can release a Seigo reference to a file descriptor via closef() during polling the Seigo

RE: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread Seigo Tanimura
On Tue, 08 May 2001 08:21:55 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 08-May-01 Seigo Tanimura wrote: Here is another issue. PROC_LOCK may block to acquire a process lock, during which an event of interest may occur or the remaining time of select(2)/poll(2) may run out.

RE: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread John Baldwin
On 09-May-01 Seigo Tanimura wrote: On Tue, 08 May 2001 08:21:55 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 08-May-01 Seigo Tanimura wrote: Here is another issue. PROC_LOCK may block to acquire a process lock, during which an event of interest may occur or the remaining

Re: RE: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread Matt Dillon
There are several issues here: * The process's descriptor table * The struct file's referenced by that descriptor table * The object underlying a struct file. A process's descriptor table is not protected by the proc lock, because the descriptor table can be shared

Re: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread Seigo Tanimura
On Wed, 9 May 2001 13:33:54 -0700 (PDT), Matt Dillon [EMAIL PROTECTED] said: Matt * The process's descriptor table Matt * The struct file's referenced by that descriptor table Those are in my TODO list, and I have already started working on them. -- Seigo Tanimura [EMAIL PROTECTED]

Re: select(2) converted to use a condition variable, and optimis

2001-05-09 Thread Seigo Tanimura
On Wed, 09 May 2001 09:21:09 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: Now the problem is whether it is easy or difficult to free a file descriptor with holding a process lock. At the level of the file descriptor layer, we can convert the memory allocator of a file descriptor from

RE: select(2) converted to use a condition variable, and optimis

2001-05-08 Thread Seigo Tanimura
On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John You need the lock when clearing the bit in p_flag. That is why the proc locks John are there, so all those proc locks need to stay. When you clear a bit, you are John writing all the bits, so you need to

RE: select(2) converted to use a condition variable, and optimis

2001-05-08 Thread John Baldwin
On 08-May-01 Seigo Tanimura wrote: On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John You need the lock when clearing the bit in p_flag. That is why the proc locks John are there, so all those proc locks need to stay. When you clear a bit, you are

Re: select(2) converted to use a condition variable, and optimis

2001-05-07 Thread John Baldwin
On 06-May-01 Alfred Perlstein wrote: * Seigo Tanimura [EMAIL PROTECTED] [010506 04:40] wrote: http://people.FreeBSD.org/~tanimura/patches/selectopt.diff Please do not remove the spl calls, they serve as a useful guide for making finer grained locks as well as error checking the new

RE: select(2) converted to use a condition variable, and optimis

2001-05-07 Thread John Baldwin
On 06-May-01 Seigo Tanimura wrote: As conversion of select(2) from msleep(9) to a condition variable is in the SMPng TODO list, I have done that task. Also, we do not have to lock a process in order to evaluate the result of {sel,poll}scan() and the remaining time of {select,poll}(2). It