[Ns-developers] [ns3] a synchronous socket/posix API

[Gustavo Carneiro]

On 05/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> On Fri, 2008-04-04 at 15:50 -0700, Sam Jansen wrote:
> > Looks like it is based on makecontext et. al., which are now
> > deprecated POSIX functions (see
> > http://www.opengroup.org/onlinepubs/000095399/functions/makecontext.html
> > ). These functions allow one to save and switch stack space, which
> > allows you to implement co-operative multitasking in user space.
>
>
> If they are deprecated, do they have a proposed replacement ?


On that URL it says """

The obsolescent functions
*getcontext*()<http://www.opengroup.org/onlinepubs/000095399/functions/getcontext.html>,
*makecontext*(), and *swapcontext*() can be replaced using POSIX threads
functions.

"""

I guess with makecontext/swapcontext could be implemented with several
threads, of which only one thread at a time is allowed to run, and a
"manager thread" scheduling which specific thread can run at any time, using
thread synchronization primitives.

> Practically, newer versions of glibc on Linux have an implementation
> > of this, at least for i386 and amd64. It appeared somewhen in the
> > 2.3.x series of glibc I think. FreeBSD and Darwin also have
> > implementations in their libc implementations as far as I know. I
> > don't know how wide ranging support for this is, when I looked into
> > these a few months ago I found support lacking in some areas.
>
>
> The osx ucontext-based version seemed to work fine when I tested it a
> while ago. I also wrote a ppc osx and an x86 linux assembly version 2
> years ago I think but since none of these seemed to provide any extra
> feature on top of this basic makecontext/swapcontext implementation, I
> got rid of them.
>
>
> >
> > It might be useful to have a threads based implementation and fall
> > back to that when these aren't available. I've done this with threads
> > in the past which isn't too hard, but I found efficiency to be lacking
> > a bit. Do you test performance at all Mathieu?
>
>
> No, I have never tested the performance of this approach, although, yes,
> performance is the classic argument in favor of coroutines since they do
> not require an extra syscall for each context switch. I expect that, in
> our case, where the user code does not do much cpu-intensive tasks,
> switching time will dominate so, coroutines will most likely be a
> serious performance gain.
>
> However, I have to confess that performance is not the main reason I
> picked this approach: I found it easier to implement it that way because
> I did not have to worry about locking.


The reason why I asked is related to where these "fiber threads" fit in the
global picture.  If you say these should be used for integration of real
world applications with NS-3, I think that is fine.  But if you open the
door for generic simulation models using coroutines then I think portability
and performance should be evaluated first.   I think you know these answers
already, but the ns-developers audience probably doesn't, so... :-)

On a related note, on my wishlist / todo list is Python based coroutines,
something like this for NS-3:
http://www.async.com.br/projects/kiwi/api/kiwi.tasklet.html

The Python coroutines solution would be extremely portable, although rather
slow when compared to C, like all Python code is... :P

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert