All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>,
	Trevor Woerner <twoerner@gmail.com>,
	seebs@seebs.net
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: long (never ending?) do_install for adwaita-icon-theme
Date: Mon, 28 Aug 2017 15:43:49 +0100	[thread overview]
Message-ID: <1503931429.32591.284.camel@linuxfoundation.org> (raw)
In-Reply-To: <a8c771fb-2b49-131d-cbc4-d885a6701279@linux.intel.com>

On Mon, 2017-08-28 at 13:38 +0300, Alexander Kanavin wrote:
> On 08/27/2017 07:07 PM, Richard Purdie wrote:
> > 
> > > 
> > > > 
> > > > On 08/22/2017 09:46 PM, Trevor Woerner wrote:
> > > > > 
> > > > > $ strace -p 43675
> > > Process 43675 attached
> > > read(1025,
> > And the answer is staring me in the face. select() only supports
> > FDs up
> > to 1024. 1025 > 1024 which is > FD_SETSIZE.
> > 
> > Therefore pseudo hangs when we run into large numbers of fds :/.
> > 
> > https://access.redhat.com/solutions/488623
> > 
> > So I think we might at least understand what is breaking. It may be
> > using poll/epoll would work instead?
> What I don't understand is how exceeding the fd limit in select()
> leads 
> to read() that never finishes. Can you clarify the sequence please?

The bitfield operation that says "can I read this fd?" probably
overflows into the next data item in the structure (I haven't checked
exactly how it fails). It may be "set", certainly the case I debugged
had to have thought it was and the code thinks "fd 1025 is ready for
reading" when in fact it may not be. The code then calls read() on it
and if it wasn't ready for reading, it would block.

Cheers,

Richard




  reply	other threads:[~2017-08-28 14:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 17:32 long (never ending?) do_install for adwaita-icon-theme Trevor Woerner
2017-08-22 17:40 ` Richard Purdie
2017-08-22 18:01   ` Alexander Kanavin
2017-08-22 18:46     ` Trevor Woerner
     [not found]       ` <e165f760-1c1e-1a5f-2fba-f8c293a16278@intel.com>
2017-08-23 12:48         ` Alexander Kanavin
2017-08-27 16:01         ` Richard Purdie
2017-08-27 16:07           ` Richard Purdie
2017-08-28 10:38             ` Alexander Kanavin
2017-08-28 14:43               ` Richard Purdie [this message]
2017-08-28 15:14                 ` Alexander Kanavin
2017-08-28 15:27                   ` Alexander Kanavin
2017-08-28 16:22                     ` Richard Purdie
2017-08-28 17:53             ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1503931429.32591.284.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=seebs@seebs.net \
    --cc=twoerner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.