[Xorp-users] (no subject)

[Mark Handley]

>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.