-2

It is not clear to me what is the relationship between the two: would be correct to say that event driven programming is a programming methodology and green threads as well as event libraries (like libev in c) follow this kind of method?

Jarod42
  • 203,559
  • 14
  • 181
  • 302
HDenied
  • 37
  • 6
  • 1
    To my understanding, the runtime environment does interrupt and scheduling for green threads in a similar way native threads are handled (with certain limitations) but I wouldn't call the usage of green threads event-driven (at least from the perspective of the user). Why do you think that green threads are event-driven. – t.niese Feb 11 '21 at 14:10
  • I think what is confusing me is the usage of a loop for the event for event driven programming and also for the green thread. – HDenied Feb 12 '21 at 16:00
  • It always depends on the perspective. From the perspective of the kernel/runtime handling/managing of threads, their context switching, … this task is likely to be event-driven. From the perspective of the one using the threads, it is not. – t.niese Feb 12 '21 at 17:01

3 Answers3

1

Event driven programming and green threads aren't directly related.

However; if a process using green threads calls a blocking system call the entire process (all of its green threads) will become blocked (and that would be horrible for performance). To work around that some form of asynchronous system calls must be used instead; but all asynchronous system calls must have some way of notifying the process that the status of asynchronous operation has changed (e.g. a notification sent by kernel to say "That file data you wanted to read asynchronously has been read successfully").

In other words, "events" (notifications from kernel saying that the status of asynchronous operation/s have changed) end up being important for the implementation of a well performing green thread run-time.

Of course the implementation of the run-time has little to do with what programmers using that run-time actually see. E.g. programmers using the run-time might use blocking IO and not use any events or event driven programming (and that blocking IO may be emulated by a run-time using asynchronous IO and events/notifications).

Brendan
  • 35,656
  • 2
  • 39
  • 66
0

Here is some information about the relation between event-driven programming and threads. What is event-driven programming?

I have no idea why to single out green threads in this regard, that's just a question of how threading is implemented. How did you get to your question?

To literally answer your last question: no, green threads don't follow an event-driven methodology.

Gnoom
  • 183
  • 6
  • I got to my question wondering what is scheduling the handlers for event driven programming and what is scheduling the coroutines/subroutines in green threads – HDenied Feb 15 '21 at 11:50
-1

Both envisage the usage of a loop that is why I was thinking about an analogy, both shouldn't use the OS scheduler to run (except for the fact thar run on main thread), if I am correct....

HDenied
  • 37
  • 6
  • I don't think there's anything about green threads (or native threads for that matter) that indicates a reliance on a loop. Threads often employ loops to perform some work in an ongoing manner, e.g. processing items in a queue, but they can just as easily do some work and then exit, much as an entire program may loop to do ongoing work or just do some work and then exit. You seem to be jumping to conclusions about threads. – Caleb Feb 12 '21 at 16:39
  • You are right, as far as I understood they rely (Green thread) either on a VM or a library, I guess the only similarity between events handlers scheduled by a loop and the coroutine scheduled by green thread is that both don't rely on the OS scheduler to run. As far as concerns the rest, event driven library seems to trigger handlers based on FD changes, while green threads, as I said, rely on libraries and/or VMs. Do you think now I am making a fair distinction or am I missing something? – HDenied Feb 15 '21 at 11:45