IssueRaiser

For your own sanity, you want some control over which thread is processing a packet, and at what point it does so.

For your own sanity, you want some control over which thread is processing a packet, and at what point it does so. The easiest way to do this is to explicitly notify the kernel when you are in fact interested in another packet, and whether you wish your thread of control to be suspended until such a packet arrives if there is no next packet. The JavaScript model of "call some callback when the currently-executing function returns" doesn't work, because C is not event-based. The embedded model of "interrupt whatever's happening and invoke some handler on the current thread of control" is just an absolute nightmare to deal with.

Posted by colanderman on Jun 16, 2015, 5:35 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.6,000 issues0 comments

complaint (Other)

For your own sanity, you want some control over which thread is processing a packet, and at what point it does so.

colandermanJun 16, 2015, 5:35 PM

For your own sanity, you want some control over which thread is processing a packet, and at what point it does so. The easiest way to do this is to explicitly notify the kernel when you are in fact interested in another packet, and whether you wish your thread of control to be suspended until such a packet arrives if there is no next packet. The JavaScript model of "call some callback when the currently-executing function returns" doesn't work, because C is not event-based. The embedded model of "interrupt whatever's happening and invoke some handler on the current thread of control" is just an absolute nightmare to deal with.

Comments (0)

No comments yet. Start the discussion.

Comment on this issue