• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Problems with poll()/write() on non-blocking sockets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with poll()/write() on non-blocking sockets


  • Subject: Re: Problems with poll()/write() on non-blocking sockets
  • From: Eric Ogren <email@hidden>
  • Date: Wed, 26 May 2010 09:51:23 -0400

(reforwarding to list since original bounced)

Sent from my iPhone

On May 26, 2010, at 9:41 AM, Eric Ogren <email@hidden> wrote:

Hi Jakub - you may want to investigate the snd_lowat socket option. The Darwin implementation of poll() ignores this option so it may report a socket writable even when the actual write() call will fail. setting the lowat to 1 fixed this issue for me.

Eric

Sent from my iPhone

On May 26, 2010, at 9:11 AM, "Jakub Bednar" <email@hidden> wrote:

Hello everyone,

during stress testing of my network application I have found some strange behavior of Mac OS X sockets.
I have a communication thread, that calls a poll() checking whether data can be written to a non-blocking
socket. Upon exit from this function I check for POLLERR or POLLHUP and then perform a write() to the socket.
If the write returns -1 and errno is set to EINTR or EAGAIN, I go back to poll. Otherwise I close the socket as there
was an error.


This works great most of the time, but during stress testing I found out a strange behavior (e.g. after 8 hours of
video streaming). The poll() unblocks the socket and call to write () returns -1 with errno EAGAIN immediately.
I go back to poll() and the same happens again leading to busy loop.


I found one post telling that it is correct for poll() to unblock a socket and that the socket can become non-writable
before I manage to call write(), but this is happing all the time for my socket and never recovers. Should I
consider EAGAIN to be an error and close the connection? Wouldn't this cause another problems? I can't see
another way out of this issue and I don't even understand why this is happening. I'm not asking for nor handling
OUT-OF-BAND data flags in poll() but I don't think it could cause the problem.


Another thing is, that Shark's System Trace keeps telling me that the syscall write returned 0x0 and not -1.
Maybe a bug in C library?


Can anyone please help me out of this or explain why is this happening?

Thanks a lot,

Jakub _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Problems with poll()/write() on non-blocking sockets (From: Jakub Bednar <email@hidden>)

  • Prev by Date: Problems with poll()/write() on non-blocking sockets
  • Next by Date: Re: Problems with poll()/write() on non-blocking sockets
  • Previous by thread: Problems with poll()/write() on non-blocking sockets
  • Next by thread: Re: Problems with poll()/write() on non-blocking sockets
  • Index(es):
    • Date
    • Thread