nwrap: catch NULL list in nwrap_add_hname_add_to_existing
[kai/samba-autobuild/.git] / prog_guide4.txt
index a815c27f862651d1f277e999b2de5ed8831b5223..0a33284e579a31c8d751b8e930778ff21100fdaf 100644 (file)
@@ -267,7 +267,7 @@ parser where to find the following four variables, but they should
 In Samba3 there were unwritten rules about which variables in a
 structure a high level caller has to fill in and which ones are filled
 in by the marshalling code. In Samba4 those rules are gone, because
-the redundent artifact variables are gone. The high level caller just
+the redundant artifact variables are gone. The high level caller just
 sets up the real variables and the marshalling code worries about
 generating the right offsets.
 
@@ -286,10 +286,10 @@ read the comment in smb_interfaces.h about that now.
 
 So, here is another rule to code by. When writing an interface
 structure think carefully about what variables in the structure can be
-left out as they are redundent. If some length is effectively defined
+left out as they are redundant. If some length is effectively defined
 twice on the wire then only put it once in the packet. If a length can
 be inferred from a null termination then do that and leave the length
-out of the structure completely. Don't put redundent stuff in
+out of the structure completely. Don't put redundant stuff in
 structures!
 
 
@@ -405,20 +405,6 @@ calls this function when it is ready. Also notice that reply_getatr()
 only does the parsing of the request, and does not do the reply
 generation. That is done by the _send() function.
 
-The only missing piece in the Samba4 right now that prevents it being
-fully async is that it currently does the low level socket calls (read
-and write on sockets) in a blocking fashion. It does use select() to
-make it somewhat async, but if a client were to send a partial packet
-then delay before sending the rest then smbd would be stuck waiting
-for the second half of the packet.
-
-To fix this I plan on making the socket calls async as well, which
-luckily will not involve any API changes in the core of smbd or the
-library. It just involves a little bit of extra code in clitransport.c
-and smbd/request.c. As a side effect I hope that this will also reduce
-the average number of system calls required to answer a request, so we
-may see a performance improvement.
-
 
 NTVFS
 -----