[bugs #9798] DO does not work in multithreaded program if lots of threads are created

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9798] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Tue 08/24/04 at 08:14 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Thanks for the report.  I believe this is now fixed in CVS.
The problem was that when using DO between threads, both threads have a copy of 
each port, so killing a connection would not invalidate the ports and the 
underlying network handles would therefore not be closed.
Now, when a connection is invalidated, it determines the underlying network 
connection in use (GSTcpHandle or GSMessageHandle) and specifically invalidates 
that handle.
This leaves the ports intact (another connection may be using them) unless 
there was only one handle in the port.






/**************************************************************************/
[bugs #9798] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9798>
Project: GNUstep
Submitted by: Willem Rein Oudshoorn
On: Wed 07/28/04 at 09:57

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  Fixed
Privacy:  Public
Assigned to:  None
Status:  Closed


Summary:  DO does not work in multithreaded program if lots of threads are 
created

Original Submission:  If DO are used to communicate between threads and
lots of threads are created DO will stop functioning.
This is demonstrated in the attached program.

As far as I can tell the following is happening.

The crash/exception is caused by the fact
that the number of file descriptors we are
waiting for in the select call is larger than the
OS limit FD_SETSIZE (=64). 

These file descriptors are used in the main thread listening
to the request from the other threads.
So this is to be expected if we have 64 threads talking
to the main thread at the same time.
But even at any given time no more than 2 threads exists,
the problem is still there.   It seems that if a thread
is finished, the main thread does not know that it can 
stop listening and keeps the GSTcpHandles around. 

Unfortunately I am a little bit lost in the DO code,
so I hope someone has some idea how to solve this.

BTW:  I have only tested this on MinGW.  So it could
be MinGW specific.

Wim Oudshoorn.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Tue 08/24/04 at 08:14         By: Richard Frith-Macdonald <CaS>
Thanks for the report.  I believe this is now fixed in CVS.
The problem was that when using DO between threads, both threads have a copy of 
each port, so killing a connection would not invalidate the ports and the 
underlying network handles would therefore not be closed.
Now, when a connection is invalidated, it determines the underlying network 
connection in use (GSTcpHandle or GSMessageHandle) and specifically invalidates 
that handle.
This leaves the ports intact (another connection may be using them) unless 
there was only one handle in the port.






File Attachments
-------------------

-------------------------------------------------------
Date: Wed 07/28/04 at 09:57  Name: nsconnection-test.tar.gz  Size: 1.02KB   By: 
wim
Program to reproduce the crash
http://savannah.gnu.org/bugs/download.php?item_id=9798&amp;item_file_id=1540






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9798>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/