On Mon, Apr 22, 2013 at 1:55 PM, liu ping fan wrote:
> On Fri, Apr 19, 2013 at 4:21 PM, Jan Kiszka wrote:
>> On 2013-04-19 02:18, liu ping fan wrote:
>>> On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka wrote:
On 2013-04-17 10:39, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Slirp a
On Fri, Apr 19, 2013 at 4:21 PM, Jan Kiszka wrote:
> On 2013-04-19 02:18, liu ping fan wrote:
>> On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka wrote:
>>> On 2013-04-17 10:39, Liu Ping Fan wrote:
From: Liu Ping Fan
Slirp and its peer can run on different context at the same time.
>>>
On 2013-04-19 02:18, liu ping fan wrote:
> On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka wrote:
>> On 2013-04-17 10:39, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Slirp and its peer can run on different context at the same time.
>>> Using lock to protect
>>
>> What are the usage rules for t
On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka wrote:
> On 2013-04-17 10:39, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Slirp and its peer can run on different context at the same time.
>> Using lock to protect
>
> What are the usage rules for this lock, what precisely is it protecting?
> Is it
On 2013-04-17 10:39, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Slirp and its peer can run on different context at the same time.
> Using lock to protect
What are the usage rules for this lock, what precisely is it protecting?
Is it ensured that we do not take the BQL while holding this one?
From: Liu Ping Fan
Slirp and its peer can run on different context at the same time.
Using lock to protect
Signed-off-by: Liu Ping Fan
---
slirp/slirp.c | 16 ++--
slirp/slirp.h |3 +++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/slirp/slirp.c b/slirp/slir
