Home/ Questions/Q 3227194
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T16:32:45+00:00

My question is pretty simple: how is event-driven programming actually achieved? To elaborate: I

  • 0

My question is pretty simple: how is event-driven programming actually achieved?

To elaborate: I have a Rails application, every time a user makes a change on the website, the model writes that “change” to a text file (as JSON.)

What I’d like to do is hook an IRC bot to that “event.” (the creation/modification of the text file.)

How is this done in general? It seems like it’d basically be an infinite loop. In pseudocode:

while (I'm Listening)
do
  if (output.txt Is changed)
    process("output.txt")

If this is how event-driven programming is achieved – how does it avoid locking up the CPU? As infinite loops have a tendency to do?

Edit-
The IRC server/bot are hosted on a locally maintained box. The Rails application is hosted on a shared server. As of now, the only way I know for my IRC bot to communicate with the Rails app is via an HTTP request to the server (or something similar.) As I stated though, this question is really more general, as I’d like to garner a knowledge of event-driven programming in general.

I apologize if this question is impossibly simple, but my understanding of event driven programming consists of attaching pre-made event handlers to objects with jQuery; which really doesn’t help when attaching an IRC bot [written in Ruby] to file I/O.

Thanks,
Robbie

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Maybe you should create a DRb server or use a solution which uses this, like delayed_job. You can run the workers on different machines. The connection is made by connecting to a special port on your server. All you need to do is open this port on your firewall for the dedicated machine running the IRC bot. You can put ruby objects on the queue, so every change to the file can be mirrored by putting a ruby object on the queue which also contains this change. The worker will grab this a few seconds later, it will not be instant. But it’s still pretty fast, uses low CPU and it is able to handle network outages.

    • 0