On Wed, 09 May 2001 19:20:07 +0900,
Seigo 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 eve
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
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 hol
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
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 protect
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
>> descrip
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 PROTECT
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 acros
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 t
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 ru
On Wed, 09 May 2001 19:20:07 +0900,
Seigo 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> descriptor
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,
> y
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
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).
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
15 matches
Mail list logo
