On Nov 24, 2016, at 2:40 PM, Michael Hall wrote: >> On Nov 24, 2016, at 2:06 PM, Alex Zavatone <z...@mac.com> wrote: >> >> How long does it take before it stops? Is that time consistent? > > kqueue seems to stop posting events as soon as the java code starts waiting > for it to post them. > The kevent wait looks currently looks like this… > > n = kevent64( queueFD, NULL, 0, &ev, 1, 0, &timeout ); > > With the timeout included this will return control to my code but with no > events posted. > >> >> If it is, what is driving the event broadcasting and what conditions are >> causing it so stop? >> > See above. There are many events pending but they seem to stop posting once > java processes it’s first batch and goes into a wait for more. > >> Is there a way for your event broadcaster to fire off a useless heartbeat >> every 15 seconds so that you can see that it's alive and you can monitor the >> log just for the heartbeat in another window so that you can catch when it >> stops and see what conditions changed to make it stop? > > As above, with no timeout the code never posts. With a timeout it > successfully returns to my code but no events are posted. >> >> A few years ago, when running one app in the iOS Simulator, I used to >> redirect NSLog to a file on my HD that I could tail in the a terminal window. >> >> Then I'd open up n+1 terminal windows, with each one tail-ing the log file. >> I'd use AWK or SED or something to pattern match and filter the output so >> that each window would track specific conditions and output. >> >> This made it convenient to monitor the patient (the app) and keep track of >> specific conditions on a per window (per readout) basis. > > Not sure I’m following. I can output messages fine. But I’m not sure what I > can put in them that will tell me anything since nothing is actually > happening. > > Michael Hall >
Yeah, I was trying to see if it would be possible for whatever service is failing to send events to display periodic output that would help you determine what stops working and why. I'll send you some samples offline that might help. Cheers. > > >> >> >> GL. >> >> >> On Nov 24, 2016, at 1:52 PM, Michael Hall wrote: >> >>> This is not entirely Cocoa, it is java, but it involves ObjectiveC JNI, the >>> java native interface. >>> Also a little bit of a long story, my apologies. >>> Specifically the question concerns kqueue, my code is based on the Uli >>> Kusterer ObjectiveC interface to that. >>> Java nio.2 introduced the WatchService class, this monitors directories and >>> tells you of any file system changes. >>> For OS X the implementation is a pure java polling one. Unlike about every >>> other platform where they are native based. >>> I tried to write a native OS X one based on kqueue. >>> I got it so that it passes the nio.2 Basic WatchService tests. >>> There is another set of tests for the code under load. LotsOfEvents. I ran >>> into what seems a deadlock condition between the java code and the kqueue >>> code. >>> Left it at that months if not years ago, but the code was sitting up on >>> github. >>> I noticed someone had recently forked it. I looked at their fork out of >>> curiosity and they said LotOfEvents ran. >>> I figured some minor miracle had occurred. I finally sat down and looked at >>> it today and unfortunately it is just that I left the code in a state where >>> it didn’t do the actual test to see if it was successful, which it is not, >>> but instead just runs through and finishes without indicating any errors. >>> So it just looked like it worked. >>> >>> What the test code does is fire a lot of events. It processes what it has >>> and then waits to see if it gets more. >>> >>> For some reason while it waits for more events kqueue stops posting events >>> entirely. If you check for anything returned the test fails. >>> If you don’t, but let the test to continue to run. kqueue happily resumes >>> pumping events with the debug messages making it look like it works. >>> >>> Any thoughts? I thought I’d ask here before I spend a whole lot of time (or >>> LotsOfTime) spinning wheels back at square 1 again. >>> >>> Michael Hall >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com >>> >>> This email sent to z...@mac.com >> > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
