| |
"Markus L. Noga" wrote:
> Actually, you wouldn't have to change much, just treat P_SUSPENDED tasks
> like they're P_WAITING and the condition failed. suspend(pid) and
> resume(pid) wouldn't really need signals that way, as the pid equals the
> address of the
> process data block - we could manipulate it directly.
That is true.
>
> > I'd expect to wait for a datagram by doing the wait_event() thing. Either
> > explicitly or wrapped in a function which also grabs the datagram from my
> > task's point of view.
>
> Uh, what about datagrams arriving faster than the task can handle,
> because it is low priority? We need buffers somewhere.
Yes, we do, but is that something the tasks need to worry about? If the
kernel has buffered 3 datagrams since the last timeslice, the next 3
waits would return immediately, since their criterion (datagram ready
for reading) would be satisfied. How many datagrams to buffer is an
implementation issue. You could force tasks to allocate their own
buffers and notify the kernel of their existence for use with one or
more port numbers.
Ah, I think I see where you're coming from. The naked wait_event
doesn't work that way; it yields the rest of the timeslice. Then we're
back at the wrapper function. Test to see if a datagram is ready to
read, and if none are, then yield on a wait_event.
Then again, UDP is, by definition, unreliable.
|
|
Message is in Reply To:
 | | Re: Idle process
|
| (...) Yes, it's a start byte. Jacob suggested using 0xFn to identify protocol versions, 0xFF being the LEGO standard. (...) Actually, you wouldn't have to change much, just treat P_SUSPENDED tasks like they're P_WAITING and the condition failed. (...) (26 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
|
10 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
