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 malloc(9) to the zone allocator, which locks only the
>> zone state for file descriptors by a mutex.
John> Free'ing is not all that problematic since it doesn't sleep. It is more
John> problematic atm because it can result in lock order reversals due to lockmgr
John> headaches. Eventually this won't become an issue I hope.
>> It is a crucial issue to release an object underlying a file
>> descriptor. Releasing a vnode can result in calling msleep(9) for
>> locking the vnode in vrele(). Releasing a socket may end up with
>> calling tsleep(9) for draining data if SO_LINGER is set. Hence we
>> cannot scan file descriptors with holding a process lock for now.
John> Argh, ok. Eventually this issue may go away as well.
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
properly (and we have to do it anyway).
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
