BIND 10 #183: UNIX domain socket for msgq

BIND 10 Development do-not-reply at isc.org
Wed May 26 09:49:41 UTC 2010


#183: UNIX domain socket for msgq
-----------------------------+----------------------------------------------
 Reporter:  larissas         |        Owner:  jinmei                     
     Type:  defect           |       Status:  reviewing                  
 Priority:  major            |    Milestone:  04. 2nd Incremental Release
Component:  message-library  |   Resolution:                             
 Keywords:                   |    Sensitive:  0                          
-----------------------------+----------------------------------------------
Changes (by jelte):

  * owner:  jelte => jinmei


Comment:

 Ok i have addressed almost all of your issues, except two, which I'm not
 sure about, see below. But first some comments about what i did in r1933;

 - Those pass statements shouldn't have been there, nor should the
 commented-out lines, so i removed them.
 - I have added a session_unittest file, which right now *only* tests for
 that big filename exception (which is now thrown instead of cutting the
 file), i think we should make a seperate task for writing tests for this
 (since there didn't appear to be any, and most of the other tests are imho
 out of scope for this ticket).
 - Re-add the environment variable again (and added a try-catch block to
 the tests, if prefix/install dirs aren't available the test would have
 failed

 For the not-larger-than-sun_path check, do you think we should make the
 test so that it checks for the boundary (which differs per system) or
 leave it like this, at something that is certainly too big?

 And the two other things;

 - SIN/SUN_LEN, I could add it, i was looking at configure and i think the
 way it is in trunk doesn't work (is SIN_LEN defined on your system?
 configure checks for another field than the one used in that ifdef
 statement...), if it is needed i can make a check for .sun_len and set it
 - Do you propose to not make a default value and explicitly use
 establish(NULL) in auth? (well actually, we should probably add a -m
 <path> option to auth in the first place. I left in the default value so
 as not to break compatibility, and changing the interface was hard enough
 as it was, with boost.asio and the pimpl idiom there :p

 But I don't have a strong opinion, and have no problem removing the = NULL
 there.

-- 
Ticket URL: <https://bind10.isc.org/ticket/183#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list