[Click] Userlevel Click task schedule

[Eddie Kohler]

Hi Beyers, again apologies for the delay!

Without looking at the code, it's hard to tell for sure, but you should 
know that Click's core is not thread safe.  It is not surprising that a 
reschedule() in thread 2 (with Click running on thread 1) could get lost 
or even corrupt memory.

I would implement this a little differently.  For example with a pipe. 
In the element's initialize() method, create a pipe with pipe() and make 
it nonblocking with fcntl(F_SETFL, O_NONBLOCK).  In Thread 2, when 
FromMyDevice receives a packet, it writes a byte to the pipe.  In Thread 
1 (the main Click thread), add_select(_pipe[0], SELECT_READ).  The 
element's selected() method will read as many bytes from the pipe as 
possible and reschedule the task.  (Will explain further if necessary.)

This is a lot of crap to go through to just reschedule a task, but 
absent a thread-safe core, it is unfortunately necessary.

Eddie


Beyers Cronje wrote:
> Hi all,
> 
> I have a question regarding userlevel Click task scheduling.
> 
> I have the following click config:
> 
> FromMyDevice -> Discard;
> 
> FromMyDevice implements a separate dedicated thread to communicate with the
> physical interface. This second thread receives packets from the physical
> device and stores then in an internal queue and then calls reschedule() on
> the task. FromMyDevice::run_task() then pulls the packets from the queue and
> pushes them through the normal Click configuration. The problem is that
> calling reschedule() from the second thread doesnt seem to work as the task
> is never rescheduled. If I do away with reschedule and only make use of
> fast_reschedule inside run_task() everything works 100%, but there's too
> much wasted cpu cycles with this method.
> 
> Does anyone have any idea how I can go about it?
> 
> Thanks
> 
> Beyers Cronje
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click