Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
Jan Kiszka wrote:
> ...
> A patch says more than thousand words. ;)
>
> As a first approach, I picked the second variant and implemented a new
> function called rt_p
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
A patch says more than thousand words. ;)
As a first approach, I picked the second variant and implemented a new
function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
rt_pipe_free so that the
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> ...
>>> A patch says more than thousand words. ;)
>>>
>>> As a first approach, I picked the second variant and implemented a new
>>> function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
>>> rt_pipe_free so that
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
Jan Kiszka wrote:
> ...
> A patch says more than thousand words. ;)
>
> As a first approach, I picked the second variant and implemented a new
> function called rt_p
Jan Kiszka wrote:
Jan Kiszka wrote:
...
A patch says more than thousand words. ;)
As a first approach, I picked the second variant and implemented a new
function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
rt_pipe_free so that the right pool is used by them.
I thought ab
[EMAIL PROTECTED] wrote on 22.11.2005 11:21:09:
> Jan Kiszka wrote:
> > ...
> > A patch says more than thousand words. ;)
> >
> > As a first approach, I picked the second variant and implemented a new
> > function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
> > rt_pipe_free so
Jan Kiszka wrote:
> ...
> A patch says more than thousand words. ;)
>
> As a first approach, I picked the second variant and implemented a new
> function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
> rt_pipe_free so that the right pool is used by them.
>
I thought about this v
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
A patch says more than thousand words. ;)
As a first approach, I picked the second variant and implemented a new
function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
rt_pipe_free so that the
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> ...
>>> A patch says more than thousand words. ;)
>>>
>>> As a first approach, I picked the second variant and implemented a new
>>> function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
>>> rt_pipe_free so that
Jan Kiszka wrote:
Jan Kiszka wrote:
...
A patch says more than thousand words. ;)
As a first approach, I picked the second variant and implemented a new
function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
rt_pipe_free so that the right pool is used by them.
I thought ab
[EMAIL PROTECTED] wrote on 22.11.2005 11:21:09:
> Jan Kiszka wrote:
> > ...
> > A patch says more than thousand words. ;)
> >
> > As a first approach, I picked the second variant and implemented a new
> > function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
> > rt_pipe_free so
Jan Kiszka wrote:
> ...
> A patch says more than thousand words. ;)
>
> As a first approach, I picked the second variant and implemented a new
> function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
> rt_pipe_free so that the right pool is used by them.
>
I thought about this v
Jan Kiszka wrote:
> Hi there,
>
> yea, I also want to join this endless pipe discussion! ;)
>
> We ran into troubles here due to large messages that should be sent via
> native pipes. Large means larger than the default message heap, the
> system heap, of the pipe subsystem so far. That raised th
Hi there,
yea, I also want to join this endless pipe discussion! ;)
We ran into troubles here due to large messages that should be sent via
native pipes. Large means larger than the default message heap, the
system heap, of the pipe subsystem so far. That raised the question why
we should not pro
Jan Kiszka wrote:
> Hi there,
>
> yea, I also want to join this endless pipe discussion! ;)
>
> We ran into troubles here due to large messages that should be sent via
> native pipes. Large means larger than the default message heap, the
> system heap, of the pipe subsystem so far. That raised th
Hi there,
yea, I also want to join this endless pipe discussion! ;)
We ran into troubles here due to large messages that should be sent via
native pipes. Large means larger than the default message heap, the
system heap, of the pipe subsystem so far. That raised the question why
we should not pro
16 matches
Mail list logo