Skip to main content

Timeline for Asynchronous Event Handler

Current License: CC BY-SA 4.0

11 events
when toggle format what by license comment
Oct 4, 2022 at 12:28 comment added Stephen Cleary @FatalSleep I have found Pipelines to be superior to events when doing async TCP/IP.
Jun 1, 2021 at 6:18 vote accept FatalSleep
May 31, 2021 at 20:40 answer added aepot timeline score: 2
May 31, 2021 at 19:09 comment added FatalSleep @aepot standard server design uses the async/await pattern with cancelation tokens. Its not overhead. The AsyncEvent isn't firing too often nor doing any sort of long sustained tasks.
May 31, 2021 at 6:13 comment added aepot Looks like you added async overhead to Server Core with no reason. OK, how many different really asynchronous subscribers to the AsyncEvent do you have? What jobs are they doing on the event was fired? What data is passed by Args? How often the event is fired, ~times/sec, peak/avg? Why I'm asking: It looks like you've solved some problem in a wrong way.
May 31, 2021 at 1:06 comment added FatalSleep @aepot the generic use here is that you can execute a bunch of different methods with similar contexts asynchronously to boost performance.
May 31, 2021 at 1:04 comment added FatalSleep @aepot in my particular situation I am using this to run events asynchronously for my async/await TCP server. Primary usefulness is that I can send data packets to events and let the events run async and continue reading data on client sockets without waiting for the events to finish from the previous data received from the client.
May 31, 2021 at 1:01 history edited FatalSleep CC BY-SA 4.0
added 6 characters in body
May 31, 2021 at 0:00 comment added aepot What's the purpose of the solution? Is it only for waiting when all the callbacks are completed? If so, here's some read.
May 30, 2021 at 23:59 history edited FatalSleep CC BY-SA 4.0
added 60 characters in body
May 30, 2021 at 0:08 history asked FatalSleep CC BY-SA 4.0