This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libfortran/30617] recursive I/O hangs under OSX
- From: "dominiq at lps dot ens dot fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Apr 2007 12:03:58 -0000
- Subject: [Bug libfortran/30617] recursive I/O hangs under OSX
- References: <bug-30617-12313@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 -------
> Please define "fixed".
For me "fixed"=="no hanging" period.
> You run an invalid program,
Yes, I know, repeating that won't help!
> all you need is change your expectations what will happen.
Bugzilla has plenty of entries "ICE on invalid", I am just asking that "hanging
on invalid" is not brushed aside just because it does happen on a platform some
people don't like.
> It is the same as if you write
> pthread_mutex_t m;
> pthread_mutex_init (&m, NULL);
> pthread_mutex_lock (&m);
> pthread_mutex_lock (&m);
> The deadlock might be detected or might not, at which point it would hang.
As far as I can tell, without knowledge of the 'pthread_mutex' mechanism, the
problem does not occur at this level, but at the level of:
pthread_mutex_unlock (&m)
pthread_mutex_unlock (&m)
where the first 'unlock' releases all the previous locks dealing with the same
unit number, leaving the second 'unlock' "waiting for something that is not
coming". Something like:
pthread_mutex_init (&m, NULL);
pthread_mutex_lock (&m);
pthread_mutex_init (&m1, NULL);
pthread_mutex_lock (&m1);
...
pthread_mutex_unlock (&m1)
pthread_mutex_unlock (&m)
is working (see comment #19), so probably if &m refers to some "event" and not
to some "unit number" (not being ashamed to show my ignorance) the problem
would disappear.
I think the following answer from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d3caadeb9083808e/78c9e65c8b4f930e?lnk=gst&q=recursive&rnum=11#78c9e65c8b4f930e
summarize the discussion
Even if this restriction on recursive input/output is
unnecessary or undesireable, it is, nonetheless, a part
of the Fortran 2003 standard.
Note the "unnecessary or undesireable", leading me to the following comments:
(1) the use of recursive I/O can be detected at run time: xlf does it;
I guess that a second locking of '&m' would not be too difficult to detect and
I don't buy the efficiency argument at this level (gfortran did not strike me
as being any faster than xlf on I/O operations);
(2) the behavior, however "processor" (fortran meaning) dependent it is, should
be platform independent: just imagine the port to OSX of a 100kloc code where
one such recusive I/O used for debuging on Linux (it works) has been left;
(3) I repeat that I am not asking for an immediate fix, only that the problem
is not forgotten due to the 'invalid' label.
Anyway, thanks for the answer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617