[Xorp-users] (no subject)

Nathan K doesnotcount@hotmail.com
Thu, 23 Sep 2004 09:52:31 -0400


Thanks for your feedback. I think what I'm going to do is have my second 
thread (not the one running the eventloop) add router connection information 
to a data structure protected by a semaphore and add a reoccuring timer to 
the eventloop and have the thread running the eventloop check for new router 
connection information, and if it exists, create a new SocketClient and 
BGPPeer object.

That should do nicely. Thanks again.

-Nathan.


>From: Mark Handley <M.Handley@cs.ucl.ac.uk>
>To: atanu@ICSI.Berkeley.EDU
>CC: Nathan K <doesnotcount@hotmail.com>, xorp-users@xorp.org
>Subject: Re: [Xorp-users] (no subject) Date: Wed, 22 Sep 2004 21:20:20 
>+0100
>
> >The XORP code was not designed to multithreaded. Having two threads in
> >the eventloop code at the same time is highly likely to be problematic.
>
>Agreed, but it's not just the eventloop - *none* of the XORP code was
>designed to be thread-safe.  This was a deliberate choice, and one I
>have never regretted - it greatly simplifies the amount anyone
>modifying the code has to undertand, and this is really important from
>an extensibility point of view.
>
>There are two minor downsides of being single-threaded in our
>framework:
>
>  - large background tasks need to be split into smaller "chunked"
>    tasks (each chunk schedules the next using a zero-second
>    timer, before returning to the event loop).
>
>  - a process receiving an XRL request can't make another XRL request,
>    receive the answer, then reply to the first XRL (because it needs
>    to return to the eventloop to receive the answer to the second XRL,
>    and this is only done by replying to the first XRL).
>
>The plus side is we don't need to lock any datastructures.
>Concurrency is *really* hard to get right.  For this sort of
>application, where timing isn't critical, I believe the upside of
>being single-threaded in terms of simplicity and code stability
>greatly outweighs the downside.
>
> >What may work is to have one thread exclusively running XORP code. Then
> >send "messages" to this thread to create new peers (or other operations).
>
>I agree that this should work.  But I'm unclear why you'd want to do it.
>
>  - Mark
>
>PS. this discussion would be better suited to the xorp-hackers list.
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.