> > > > Note that kevent(2) is a multi-purpose API. The call you refer to as (1) > is not actually the mainloop of tracelib run. Rather, the call a little > further down is: > > keventstatus = kevent(kq, NULL, 0, res_kevents, MAX_SOCKETS, NULL)) > > This will also return for new connections to the socket, which > darwintrace.dylib creates. Depending on why kevent returned, the code > will either process a line from a socket, or accept a new socket and > then eventually call kevent again. > > > Actually my question is what is the purpose of the call (1), because till what I understood, kevent(2) only lets the program proceed further when it will return and it only returns when it detects an event. Call (1) is supposed to detect a read event. I am asking where exactly that read event happens that makes that kevent return.
> I actually think it would be enough to just implement a Ctrie, but if > you can find a suitable BSD-licensed (or compatible) implementation that > you can reuse instead of re-implement you could also do the demo you > suggested. I don't mind either way. > > Ok, I will do that. > > >From what I can see, the proposal looks more detailed to me now. > However, you are not yet addressing the inherent race conditions with > the suggested approach in the shared memory area and the special > conditions required due to use of shared memory, such as not being able > to use normal pointers. > I will update the draft to add those. > > Please also look into the paper on arXiv I sent you a while ago, because > that did seem the data structure proposed there would already solve some > of our problems. > Sure, I will make it a priority. > Don't underestimate the effort required to get the data structure > implemented given the constraints of the environment. To be certain that > your data structure works as it should, you will also have to write an > extensive test suite for all functionality of the data structure, > possibly using code coverage measurements. I didn’t mean to underestimate, I already see it's really complex to deal with so many things at a time. I wanted to ask to get more clarity. Will put all effort & do the max I can. > > Additionally, if you really think you'd be done with all of that early, > you can include optional "stretch goals" that we can take up if you're > done early, such as writing a test suite for trace mode functionality, > writing documentation for the on-wire format between darwintrace.dylib > and the server, etc. > Sure, I will analyse all points again and add accordingly. Mihir
