You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by GitBox <gi...@apache.org> on 2020/04/20 16:38:08 UTC

[GitHub] [trafficserver] sudheerv commented on issue #6602: TSContSchedule API renaming

sudheerv commented on issue #6602:
URL: https://github.com/apache/trafficserver/pull/6602#issuecomment-616670924


   > I don't think we should rename TSContScheduleOnPool() to be TSContSchedule(). The function requires a pool and it makes more sense to have the name TSContScheduleOnPool(). I have mix feeling on getting rid of TSContSchedule()
   
   Yeah, I tend to agree with Bryan -  the naming of TSContScheduleOnPool() and TSContschedule() are more readable  and intuitive to relate to the intended behavior. Even though TSContScheduleOnPool() can indirectly achieve the effect of scheduling on the current thread, it feels a bit too contrived and perhaps a bit needlessly complicated that it’d only do so when the affinity is not set. As a API user, one would much rather have a simple and direct API that says TSContSchedule() that defaults to the current thread. This is actually why I didn’t like reusing TSContScheduleOnPool() naming if we wanted to kill one of the API.
   
    I dont particularly think having two separate (clearly named) API in this case is confusing or overload. Rather, repurposing one API to support too many combinations seems the more confusing option.
   
   Long story short, while I’m not -1 to condense into a single API and would be okay if everyone else feels that’s the right way to go, I’m definitely +1 on leaving the (2 separate) API as they are in ATS9 (current master). 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org