Re: [PATCH cygwin] Re: Problems of AF_INET domain socket regarding out-of-band data.

[Takashi Yano]

On Fri, 22 Jun 2018 00:05:18 +0900
Takashi Yano wrote:
> Sorry, again. Fix a typo in commit message.

Fix a typo in commit message again

-- 
Takashi Yano 


0001-Fix-the-handling-of-out-of-band-OOB-data-in-a-socket.patch
Description: Binary data

Re: [PATCH cygwin] Re: Problems of AF_INET domain socket regarding out-of-band data.

[Takashi Yano]

Sorry, again. Fix a typo in commit message.

-- 
Takashi Yano 


0001-Fix-the-handling-of-out-of-band-OOB-data-in-a-socket.patch
Description: Binary data

[PATCH cygwin] Re: Problems of AF_INET domain socket regarding out-of-band data.

[Takashi Yano]

Hi Corinna,

On Thu, 21 Jun 2018 09:19:54 +0200
Corinna Vinschen wrote:
> - The minor point: There's a typo "oub-of-band" in the comment
>   handling the SO_OOBINLINE ioctl.

Fixed. Thanks.

> - The major point: Now that INET and LOCAL sockets are handled
>   separately, we may want to follow Linux' lead:
> 
>   "UNIX domain sockets do not support the transmission of out-of-band data
>(the MSG_OOB flag for send(2) and recv(2))" (quote from `man 7 unix')
> 
>   If I ever get around to finish the new AF_UNIX implemantation it won't
>   support OOB anyway.  For the time being, we may want to disable OOB in
>   fhandler_socket_local already, so, rather than duplicating the changes
>   to AF_INET, we could simply disable OOB handling in
>   fhandler_socket_local entirely.  Care to do that?

I removed the OOB data handling from AF_LOCAL socket.

Please find a new patch attached.

-- 
Takashi Yano 


0001-Fix-the-handling-of-out-band-data-OOB-in-a-socket.patch
Description: Binary data

Re: [PATCH RFC] fork: remove cygpid.N sharedmem on fork failure

[Corinna Vinschen]

On Jun 20 17:47, Michael Haubenwallner wrote:
> On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
> > On Jun  5 15:05, Michael Haubenwallner wrote:
> >> Hi,
> >>
> >> I'm using attached patch for a while now, and orphan cygpid.N shared memory
> >> instances are gone for otherwise completely unknown windows process ids.
> >>
> >> However, I do see defunct processes now which's PPID does not exist (any 
> >> more),
> >> causing the same trouble because their windows process handle is closed but
> >> their cygpid.N shmem handle is not.
> >>
> 
> >>
> >> But I have no idea whether attached patch is causing or uncovering this 
> >> issue...
> >>
> >> Any idea?
> > 
> > Not really.  Processes are kept around after exec to keep the PID
> > blocked.  Perhaps your patch is breaking an assumption there.
> > I wonder why you have a problem with failing forks in the first
> > place...?
> 
> I'm successfully using the topic/forkables patches still, where
> fork is retried using /var/run/cygfork/ when an exe or dll was
> replaced (by some in-cygwin package manager).
> 
> Without this patch, for the first-try child process which the
> cygwin1.dll fails to initialize for because of wrong dll loaded,
> the process handle is released but the cygpid.N shmem handle is not.
> 
> Then, another completely independent process may get the same
> windows process id again, and cygwin1.dll fails to initialize
> because of the existing but orphaned cygpid.N shmem handle.

This problem appear to be a non-problem in the normal code path.  In
case of restarting the 2nd-try child, wouldn't it make sense to reuse
the shmem area instead of breaking it down?

> For those "Suspended" windows processes (sh.exe):
> They seem to occur eventually when a shell script was executing some
> native windows process (msvc toolchain). Interesting here is that
> I got *4* Suspended sh.exe on the *4* core VirtualBox machine...

That really sounds weird.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature