http://bugs.winehq.org/show_bug.cgi?id=29499
--- Comment #28 from Bruno Jesus 00cpxxx@gmail.com 2012-03-06 19:25:15 CST --- I don't think it makes sense in setting that events in this case. POLLIN (and sometimes POLLPRI) is already set so the events variable is never 0 which seems enough for MacOS. Setting POLLHUP in events in the example code was possibly a hack to get around the zeroed events variable. Even the poll() man on macos says that POLLHUP/POLLERR are ignored as expected events [1].
Also you are checking for a combined POLLERR|POLLHUP and IMO you should be checking for the flags separately, they may not come together in every OS.
Your original patches for this bug led me to understand that there was an infinite loop between recvmsg and poll. recvmsg returns -1 and then poll returns 1 showing that there is still something to do, then in the next loop iteration recvmsg returns -1 ... and so on. What I was trying to do with that patch was check what kind of event poll was returning so I could filter and break the infinite loop but that seems not enough for MacOS. The lack of console printfs from my last patch shows that poll may never be returning (due to the timeout = -1 which is used and tells poll to way forever).
[1] https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManP...