On Tue, May 08, 2001 at 04:18:31PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > With my better understanding, I would say it this way: If I call
> > mach_host_self() 2^16 and a couple times, and then call
> > mach_port_deallocate on the port name returned by these calls 2^16
> > times, then the urefs will drop to zero and the port name in the
> > port name space will be destroyed by ipc_right_dealloc. But the
> > user might expect that he has a couple of send rights (user
> > references) left.
>
> Yes, that's true. The user should know that incrementing his count
> that far has curious results. If you want to fix it, you might do so
> by inserting a change to ipc_right_dealloc that preserves the "pegged"
> value, and refuses to reduce urefs if we pegged it sometime in the
> course of adding a uref.
Right. You'd need to lower the upper limit by one so that you can decide
between a full non-overflowing port and a port that has overflown. Or,
alternatively, have an extra bit somewhere.
> Note that this can only happen if ipc_right_copyout was called with
> OVERFLOW set. A brief scan of the code (I might have missed some),
> shows that this happens only when handling kmsg's and in
> ipc_port_copyout_send; the latter is used only for mach_host_self,
> mach_task_self, and mach_thread_self.
I don't think we should bother to change anything for those. As you say:
> Ok, then the user should be sure not to deallocate them. :)
Works for me. Users can implement their own refcounting with a lock, a
counter and mach_port_destroy if they really need it. Or cache the value.
Only if at some time servers in user space were allowed to specify overflow
to be true for a receive port, then I think it might make sense to fix the
underflow side, too. But I have my doubts that this is a useful feature.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
