problem with readonly pinfo?
Wed Sep 17 23:44:00 GMT 2003
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
>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
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
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
I like opening this read only where possible. I guess we should just
hold tight until I check in my stuff. Probably this weekend...
More information about the Cygwin-developers