>
>
>
> 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
