It is quite annoying having it block indefinitely, especially when you might want something to update while listening for an event.
Example: I am updating buttons on a monitor based on an incoming modem message; if the modem message changes, the buttons will not do so accordingly until a monitor_touch event occurs, allowing the code to progress. It would be nice to have the touch monitor update itself without blocking for touch events. same goes for listening for the modem, I need to sent the message in a while loop to keep the other computers running (by constantly receiving messages they constantly trigger events, and unhanging the code)

Depending on what you are actually making i would suggest stopping relaying on pullEvent filter and actually writing code that handles multiple types of events as they go. Then your code could handle timers, monitor_touch, modem_message and all other events as required. os.startTimer() might be helpfull for planning for something to happen in future.

If you insist on using filtered pullEvent you might want to take a look at parallel API for help in getting multiple pullEvents running side by side. Take a look at examples at that page to see what i mean.

Good point, I will look into setting it up differently. I'll try setting up an event handler and see if it works

I have managed to recreate it in a profile with just cc tweaked:

1. Display something on the monitor once (not in a loop)
2. By any means, make the chunk in which the monitor is in unload (go far away, leave dimension)
3. Upon returning, whatever was displayed is missing, even though it is still there and working (referring to touch buttons)

I noticed this on a server i was playing on where the computer will wait for the monitor_touch event, i would go away, come back, and right clicking on where a button was would still activate it. It is probably a render issue somewhere.
I have found a workaround, which is checking the buttons with parallel.waitForAny along with an os.sleep(2) that periodically stops it from waiting for the event and redisplays everything

I ended up using the parallel API and made it work, however i have discovered another bug related to monitors; should i open a new issue for that?

I would post into a discussion first, you might be doing something weirdly.

i have noticed this issue with displays too. they would reset to all black if you go to far but the code would still be active.(maybe the displays need more time to fully load in than the computer needs time to run.

my simple fix was to start a timer so that when the timer event happened it would "redraw" the screen.

the issue with your code is it draws only once so if the monitor is erased by an unexpect factor it does not ever redraw it. (unless you restart your program)

I have already done that in a way, if you read the last two lines again, though the monitors should not be behaving like that I don't think

I've opened a ticket regarding that bug (#687).