On Thu, 27 Jul 2017, Boris Ostrovsky wrote:
> On 07/26/2017 08:08 PM, Stefano Stabellini wrote:
> > On Wed, 26 Jul 2017, Boris Ostrovsky wrote:
> +count++;
> +else
> +
> wait_event_interruptible(map->active.inflight
On 07/26/2017 08:08 PM, Stefano Stabellini wrote:
> On Wed, 26 Jul 2017, Boris Ostrovsky wrote:
+ count++;
+ else
+ wait_event_interruptible(map->active.inflight_conn_req,
+ pvcalls_front_read_t
On Wed, 26 Jul 2017, Boris Ostrovsky wrote:
> >> + count++;
> >> + else
> >> + wait_event_interruptible(map->active.inflight_conn_req,
> >> + pvcalls_front_read_todo(map));
> >> + }
> > Should we be using PVCALLS_
>> +while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
>> +if (count < PVCALLS_FRONT_MAX_SPIN)
>> +count++;
>> +else
>> +wait_event_interruptible(map->active.inflight_conn_req,
>> +
On 07/25/2017 05:22 PM, Stefano Stabellini wrote:
> Implement recvmsg by copying data from the "in" ring. If not enough data
> is available and the recvmsg call is blocking, then wait on the
> inflight_conn_req waitqueue. Take the active socket in_mutex so that
> only one function can access the ri
Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.
If not enough data is available on