Novice to Linux, Eclipse Helios Service Release 2

I am looking into interrupt driven programming and have not “recognized” any articles providing a good discussion for Linux. (Note that I wrote “recognized.”)

In my head that means something like: task A has made a call to the OS stating that it wants to be notified when events 1, 2, or 3 gets set. Then it hits a line of code that says wait for event. It stops all processing.

At some time task B sets one or more of those events. Task B might be the OS itself.

When that happens Task A is restarted by the OS at the next line of code the wait statement. There it checks to see which event was set and takes appropriate action, to include resetting the event.

I see some answers that reference epoll, but that would be an oxymoron. Event programming gets rid of polling. I see FDs, file descriptors, but those are positive integers and I don't recognize how to get into them to specify events.

I am not recognizing anything that looks like it says: Declare events like (this), set events like (this), wait for them like (this), and reset them like (this).

Links to tutorials or names of books will be appreciated.

I've been using libevent to handle this stuff for me.

what do you mean by "event"?
Note: select(2) and poll(2) don't actually poll, they just wait for some activity on the specified file-handles.

Event: a thing that happens, especially one of importance.
Examples: A keystroke is detected from a keyboard, a socket read or write has completed, Program A is executing a specific line of code and requests and that operating system take note of that so other programs will be aware that has occurred thereby synchronizing two or more applications.

Side comment: While I will look into poll(2) this is worth nothing for future use. Many programmers don't realize the importance of using clear and precise names. The use of the name poll() for an activity that does not poll is rather poor programming practice. Every time a person with a good command of the English language and with programming skills looks at code that says "poll()" they will, or should, immediately think of a polling operation. As that function does not poll, the use of the phrase "poll" is quite bad programming practice. Now, that name is embedded into the system and will probably never change. That rather badly chosen name will be with us for a long time.

I take the time to write this so that maybe one or more programmers will think just a little bit more and spend just a few more seconds creating well named functions and variables.

Back to the regularly scheduled question:

Program Decom spawns a task named Ethernet_Ingest to capture data via an Ethernet socket and get that data into one of two alternating buffers. Freed of that significant task, the main program waits for an event from Ethernet_Ingest signifying that buffer A has fresh data. When the event is received it examines the appropriate buffer, extracts some chunk of data and hands it off. Then it waits for the next event from Ethernet_Ingest. It does not poll, it suspends its operations and waits until the event is set.

How do I set up this communications between the main program and task Ethernet_Ingest?

I suspect a few people have been kind enough to document this in detail. I need some help in finding those pages.

Assuming you're using C?

nodejs uses libuv for that. Neovim is moving to libuv.

Note that the architecture behind all event-driven programming is the event loop Wikipedia.

If this "Ethernet Ingest" is an existing program, you have to read its documentation and/or ask its creators about its usage.

Re: Assuming you're using C?
Yes, I am using C/C++.
Hmmm. Seems to be that the event concept is independent of the programming language. If not obvious to the programmer then it should be there under the covers. Did you intend to indicate otherwise?

The answers here indicate, to me, that the event concept is not fully implemented by the kernel. Or maybe not flexible and easy to use. Libuv is something to download and install as is libevent. If there was not a need for improved event handling code then there would not be a cottage industry of just such code.

I will check back for updates but this has provided the information needed so the problem is resolved.

Thank you for taking the time to post.

I had another look at your problem description. You're thinking of signals, which are a Linux kernel service.

Here's one introductton:

http://www.linuxjournal.com/article/3985