There are no limits in terms of settings, but you need to be cognizant of some aspects.

You could use semisynchrnous replication as it uses a nice algorithm for shipping SQL to Slaves by making sure at least one server has all the latest SQL in the Slaves relay logs. (See my August 5, 2011 post https://dba.stackexchange.com/questions/4311/is-mysql-replication-affected-by-a-high-latency-interconnect/4390#4390)

However, semisynchronous replication is only good for one out of N Slaves.

Whether you have semisynchronous replication or not, it would suffice to say that the more Slaves you have, the more CPU processing a Master has to do to keep its Slaves up-to-date. 

For a Master with N Slaves, that's...

- N SQL Statements to send to Slave
- N Acknowledgments from Slaves 1-N that SQL was Executed

With semisynchrnous replication, it is not much better because For a Master with N Slaves, that's ...

- N SQL Statements to send to Slave
- Acknowledgments from Slave
 - 1 Acknowledgment that a Slave 1 received the latest SQL
 - N-1 Acknowledgments from Slaves 2-N that SQL was Executed

If you have to have many Slaves, think of using a Distribution Master in a Star Topology

- https://dba.stackexchange.com/questions/9424/best-way-to-setup-master-to-multi-master-replication/9425#9425
- https://dba.stackexchange.com/questions/3855/is-it-a-good-idea-to-split-mysql-db-into-two-servers/3863#3863
- https://dba.stackexchange.com/questions/9189/infrastructure-for-highly-concurrent-high-write-db/9398#9398
- https://stackoverflow.com/a/5784578/491757

If you cannot setup a Distribution Master in a Star Topology, then here is my simple rule: Use Semisynchrnous Replication but use as few Slaves as possible.