In the VLC source code (/modules/lua/libs/net.c), the lua vlc.net.poll({fds}) func maps to this.
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
The timeout argument specifies an upper limit on the time for which poll() will block, in milliseconds. Specifying a negative value in timeout means an infinite timeout.
So calling poll() in scripts will
introduce indefinite blocking because of that hardcoded -1.
Aside: this bit me yesterday.* Turned out vlc.net.recv() is non-blocking, returning nil instead of a string if the socket wasn't ready to be read from. So when writing a client, after connecting it's important to poll() for vlc.net.POLLIN which causes the script to wait for a server response to arrive before attempting recv. On the other hand, to make a non-blocking client, one could just recv at will and handle nils.
* I made a test server that slept for a couple seconds before telling clients "hello world" and had VLC print debug messages to confirm poll was blocking for that duration and
then letting recv kick in.
For a non-blocking server... I haven't tried this, but if accept() blocks, and poll({fds}) blocks until something's ready to act on, you could include in your fds a dummy source that's always ready to read. Poll should immediately return. Then if a non-dummy also happens to also be ready for accepting, you can handle that. Possible pitfall: If the brief poll doesn't sleep at all, it might not like being in a while loop unless you add a sleep of your own... or put the polling in a periodically-triggered event instead.