On 23 Apr 2014, at 10:47 am, jas <jas@cruzio.com> wrote:

Just guessing, here, as I don't have anything to look at
other than this post - but the symptoms you describe fit the pattern.

Snip

Probably didn't solve the problem, but, having already reasoned
that it *could* have solved the problem, and noticing that it *appears*
not to make things worse, that 'fix' stayed in.


This process is instantly recognisable to me as something I'm trying to train myself out of, though I can't take the blame this time :)

Taking that bit out of suspendIfAsync does, as you suggest, fix the immediate CPU pegging issue.

But I'm not happy yet, because I still can't do proper non-pegging IO on OS X - I can't call setOwnerIfFail: on pipes and then do the obvious:

[ pipe suspendIfAsyc. pipe dataReady ifTrue: [ doSomethingWith: pipe read ] ] loop

(or rather, I can but suspendIfAsync fails to suspend because setOwnerIfFail: fails)

Changing to pipe suspendIO in these circumstances instead (ie dropping setOwnerIfFail:) has the interesting side effect that the thread suspends *until some input on the command line causes SIGIO to be sent* - so that the pipe only reads while you hold down the enter key on Stdin :)

Reading up on how setAsync/SIGIO work reveals that, of course, BSD, Linux and Solaris all do it slightly differently. Sigh.

I've just checked and setOwnerIfFail/fcntl is working on Linux, which is why the CPU pegging isn't noticed.

Russell