Re: problem with readonly pinfo?

[Christopher Faylor <cgf at redhat dot com>]

On Wed, Sep 17, 2003 at 06:19:29PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>
>> >>"The winpids code first tries to open the shared region with RW and
>> >>then drops back to read-only if it fails."
>> >
>> >I know you wrote that and I wondered why.  I may be really confused but
>> >I don't see how handler_process::fill_filebuf () uses winpids.  It
>> >deals with pinfo's directly.  kill_pgrp uses winpids.  You fixed both
>> >the same night (late)...
>> 
>> Oops.  Right.  Sorry.  I got the two confused.  And it doesn't actually
>> make any difference for kill_pgrp.  So, yes, I think your proposal to do
>> this in pinfo::init makes sense.
>
>Yes, but I was backing away from it. In all cases I have seen (outside of
>winpids, see below) the creator of a pinfo knows if write access is
>required.
>Isn't it true even for winpids? Both kill_pgrp and talktome require write
>access to work, so opening read only does not help them (and requires
>more work).

The reason I did this for winpids is that it is difficult to catch the
error in the winpids constructor and I preferred to do it when the
individual pid was being accessed...  that plus I thought that fhandler_proc
needed it.

For the fhandler_proc case, it isn't a catastrophic error if it can't
send the pseudo-signal (now that I've modified sig_send) so I think it
makes sense.  Maybe another flag like PID_MAP_RW_MAYBE or something...

Except the pipe stuff is going to change all of this anyway, so why am
I even suggesting it?  :-)

>If we go that way (my original proposal) then we could go all the way,
>get rid of PID_MAP_RW altogether and always try to open RW then RO.
>Not that I recommend it, now that all the spots requiring RW are 
>finally identified!

I like opening this read only where possible.  I guess we should just
hold tight until I check in my stuff.  Probably this weekend...

cgf