Re: os_events manamgnent

+1 > I'm now not suggesting change what's in the core, instead, perhaps make > available a simple struct wrapper and support functions/macros as > 'codified' best practice of this pattern. > I can take a look at creating a PR once I've seen the latest Event API and > am closer to the v1.0

Re: os_events manamgnent

Thanks Chris, On 4 November 2016 at 18:11, Christopher Collins wrote: > Hi Wayne, > > Good question. I'll address the specifics below, but I should mention > that OS event handling has undergone some fairly major changes in recent > days. Later today, I will send a follow

Re: os_events manamgnent

Thanks! I was not sure about responding. Will > On Nov 4, 2016, at 9:42 AM, Christopher Collins wrote: > > (responding to Runtime only) > > I will reply to Wayne's email this morning, and follow it up with a > message to dev regarding the recent eventq changes. I just

Re: os_events manamgnent

(responding to Runtime only) I will reply to Wayne's email this morning, and follow it up with a message to dev regarding the recent eventq changes. I just wanted to send this note so no one spends time writing a response. Thanks, Chris On Fri, Nov 04, 2016 at 01:08:50PM +, Wayne Keenan

Re: os_events manamgnent

sorry for the typo'ed subject and also these corrections are required: In the first post example this line: my_event(_EVENT_QUEUE, my_event); should be: os_eventq_put(_EVENT_QUEUE, my_event); In the second post example this line: rc = my_event(_EVENT_QUEUE, OS_EVENT_T_PERUSER+1, arg );

os_events manamgnent

Hi, I had to move from the commonly found 'statically allocated' os_event usage pattern to something dynamic. This is what I'm using: // Post event: struct os_event* my_event = (struct os_event *)os_memblock_get(_mbuf_mpool); if (!my_event) { // TODO: scream loudly