65909 - [BeOS] _MD_pr_poll() always return immediately

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Takashi Toyoshima]

BeOS version _MD_pr_poll() always return immediately.
So on using socket, mozilla use a lot of CPU power.

The cause of this problem is select() of BeOS.
On BeOS, only read_bits is implemented.
So if we set write_bits, select() always return
immediately with result value that mean socket can write.

Comment 1

[Takashi Toyoshima]

Attachment: patch

Comment 2

[Takashi Toyoshima]

Attachment: revised patch

Comment 3

[Keyser Sose]

Marking NEW to get somoone to look at it.

Comment 4

[cls]

The first patch looked correct based upon the initial comments.  The second
patch appears to call select twice.  Once with the write_bits set to 0 and once
as it did before which would still cause it to return immediately after the
second select, correct?

Comment 5

[Yannick Koehler]

Which patch is correct?  anyone care to review?

Comment 6

[Yannick Koehler]

I don't think I understand that patch totally, but I've corrected the comments which was using a bad english... 

I think that the second call is needed even thought we know it's returning right away, just unsure why it is...  I'm attaching a new patch.

Comment 7

[Yannick Koehler]

Attachment: corrected comments english and removed tabs

Comment 8

[Takashi Toyoshima]

Thanks, Chris and Yannick.

By first select(), we get read bits.
But only this, we never get write bits.
So sometimes browser fail to load files
for inability to write request.
Second select is the easist way to set write bits.
So second select might not need "&rd".

By this way, we can wait for read.
But if we want to only write, two select()s always
return immediately. Of source It's bad...

Does anyone have better idea?
Is this the Mission Impossible without BONE... ;)

Comment 9

[kurros (Wade Majors)]

I have asked [e-mail] to take a look at this bug id, hoping he will be
able to provide some input.

Comment 10

[Wan-Teh Chang]

When the patch is ready, please reassign the bug
to [e-mail] for checkin.

Comment 11

[kurros (Wade Majors)]

Ham: this patch appears to break networking when applied to the current tree. Is
this bug still valid?

Comment 12

[kurros (Wade Majors)]

Whoops, sorry I used Ham there :) Takashi: as I said this bug appears to break
networking (hangs on DNS lookups).

Comment 13

[Wan-Teh Chang]

Is anyone still working on this bug?

Comment 14

[Yannick Koehler]

No more working on Bezilla

Comment 15

[cls]

After further inspection and testing, I don't think calling select() twice fixes
anything.  When _MD_pr_poll properly checks for select() return values (bug
70808), calling select twice is bad as the second call destroys any errno set by
the first call which we check.   I don't see any way around the problem if
select() doesn't work for write bits as we have no other way of determining if
the bits are writeable.  I suppose we could wait the full timeout period instead
of returning immediately but that might cause delays when there are sockets
which have their read bits set.

Comment 16

[Wan-Teh Chang]

Assigned the bug to Chris.

Comment 17

[Paul]

Is this bug still an issue?

Comment 18

[Dennis Jakobsen]

Yes, net_server uses almost 100% cpu when accessing pages..

Comment 19

[thebeastwitheyesthatstared]

It looks like this could be marked INVALID, as it looks quite old, and since 
february of 2002, several versions of bezilla, stripzilla and phoenix have 
come out on beos, it looks like. So if this is marked INVALID, and someone is 
still seing it, this could be re-opened, etc.

www.bezilla.org
http://www.bebits.com/app/2715

Comment 20

[hacker formerly known as [e-mail]]

Mass reassign to new default build assignee

Comment 21

[Wan-Teh Chang]

Marked the bug INVALID as comment 19 suggested.