https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29604
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--- Comment #7 from daney at gcc dot gnu dot org 2008-02-27 18:11 ---
Unassigning as I am not working on this.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from daney at gcc dot gnu dot org 2007-05-19 18:20 ---
That didn't come out quite right :(.
The close part would be:
int t = dup(fileDes)
dup2(global_always_error_fd, fileDes);
synchronized {
cleanupFD = fileDes;
}
close (t);
synchronized {
--- Comment #5 from daney at gcc dot gnu dot org 2007-05-19 18:12 ---
UNIX/Linux sucks.
There are likely races with read/write and close all over libgcj:
=
Thread 1 Thread 2 Thread 3
load f
--- Comment #4 from ddaney at avtrex dot com 2006-10-26 18:03 ---
Subject: Re: Race condition in ServerSocket.accept()
tromey at gcc dot gnu dot org wrote:
> --- Comment #3 from tromey at gcc dot gnu dot org 2006-10-26 17:58
> ---
> Instead of directly calling accept we could
--- Comment #3 from tromey at gcc dot gnu dot org 2006-10-26 17:58 ---
Instead of directly calling accept we could select or poll on the fd.
This would let us have a timeout or an interrupt or something.
For all I know poll would react more gracefully to another thread
closing the fd --
--- Comment #2 from daney at gcc dot gnu dot org 2006-10-26 17:56 ---
This is trickier than I initially thought.
You cannot remained blocked in accept() while holding a lock that protects
closing the native_fd. Otherwise you will be blocked until a connection
arrives (perhaps forever).
--- Comment #1 from daney at gcc dot gnu dot org 2006-10-26 17:21 ---
As noted in Comment #11 of PR15430, I think that all accesses to native_fd need
to be synchronized. That is my plan of attack for this.
--
daney at gcc dot gnu dot org changed:
What|Removed
