Or the 5.7 changes that make locking unnecessary http://dev.mysql.com/doc/refman/5.7/en/show-slave-status.html

Hi, I am Jerry H. Wolf a MS Computer science student at the University of Aachen and I will love to work on this project. I have 2 thoughts on this project.
1- We extend the SHOW SLAVE STATUS syntax to add the non-blocking clause to it then implement the logic behind it.
OR
2- We keep the current syntax and make regular SHOW SLAVE STATUS lock-free.
Im still trying to find the pros and cons of each option but if anyone has some other suggestions I will love to discuss them.

A simpler syntax is always preferable. The integrity of the show slave status is also important. If both can be achieved reliably then adding a NON_BLOCKING option isn't needed. Proposals are open so get writing https://summerofcode.withgoogle.com

Hi, Daniel,
I have been studying the grammar and I think the best approach for GSoC is we focus on adding the new syntax then we can update the parser to recognize both options as one that way we will have something like

<command options>

case SQLCOM_SHOW_SLAVE_STAT_NONBLOCKING:

case SQLCOM_SHOW_SLAVE_STAT:

  {

   res = show_slavestatus() | show_slave_status_nonblocking();

  break; 

  }

<command options>

jhunter Well your proposal is in and I've read it. Its undergoing organisational assessment and you'll be notified of the outcomes once complete. The important aspect of the non-blocking is it actually non-locking. So what locks are held currently? Which ones will be held for a long time? And what can be done to mitigate it? How does the MySQL-5.7 code achieve non-blocking?

Doesn't seem to be a driving need.