Follow-up Comment #12, bug #22351 (project gnustep):
> "If there is a problem running out of file descriptors,
> then a fix would be to use fewer of them"
Sure ... but it turns out that the problem was nothing to do with running out
of file descriptors.
> The root of the problem is that the polling in that method for a
connection
>is causing the process to block because the file descriptors allowed for
that
>process are quickly used up. This happens because, at least on linux, the
> send and receive ports are created by making special files in /tmp.
But ensuring that those descriptors are closed immediately (ie so that the
process cannot possibly run out of descriptors) did not cure the problem, and
of course the use of a large number of descriptors in one client cannot
explain why other clients could then not contact the server ... so the
descriptors were a red herring.
> Giving the server time to come up and register itself means that
> we'll do less polling
Yes ... good to poll less frequently ... I put a 0.05 of a second delay
between each poll. Enough to cut down significantly on cpu usage without
causing a discernable delay in application startup.
> and, thus, use fewer file descriptors.
Each time we poll we we re-use the same file descriptors, so frequency of
polling doesn't affect that.
Hopefully the changes to NSPortMessageNameServer.m to implement locking will
have cureed this issue by preventing two processes from interfering with each
other (your long sleep on startup would have reduced, but not eliminated, the
chance of the two processes both trying to access the port name at the same
time).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?22351>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
