> How do you know something is a leaf node? Lock claims can be arbitrarily
> fall down a call chain, after all.
I was thinking of looking at the code.
In the context of passing data to server threads, the code will be only a
page. There are 2 routines:
static: data
update_info (new):
lock_write
data = new
unlock
get_info:
lock_read
temp = data
unlock
return temp
Note that there are no calls. It's got to be a leaf node.
-------
> I don't know why this is. The Go designers did something subtle that I don't
> understand, and nobody else seems to either. I have researched this because
> I find it puzzling and interesting, and not found any plausible theory.
Thanks for your comments on this area.
> Normally the work you will do per
> item will greatly exceed the 90â250 ns it takes to move the item
> through the channel, so itâs just not worth worrying about.
That sounds like the right ballpark. Again, if I were working in this area I
would be writing hack code to generate numbers. It's got to have a buffer for
each item waiting in the channel. Does it do an alloc/free on each item or
does it avoid that by saving the buffer and reusing it? We have 3 sizes of
packets: no-auth (48 bytes), shared-key (68), and NTS (232). Can we tell it
how much to copy or will it copy worst-case?
Processing a packet takes a few uSec for no-auth and ~10 usec for NTS. A
single 250ns is not important relative to 10 usec but will be significant
relative to a few usec if you do it several times per packet.
---------
I still haven't seen how you plan to get the data from the client side to the
server side without a lock. See sample code above.
The server side does:
loop:
recv_request
get_info
fill in reply
send_reply
I suppose you could do it if channels have a peek option. That will take a lot
more code. You will need a main channel and a sub-channel per thread and
another thread to copy over. And then you have to handle the case where a
server thread is idle so it's not checking its new-data channel... Ugh.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
