1001114 - Trim unused code from sipcc for b2g/android builds

Status: RESOLVED WONTFIX

(Core :: WebRTC: Signaling, defect)

Description

[Martin Thomson [:mt:]]

There's a lot of code in sipcc that we don't use.  But it's probably linked into builds because it's still listed in the many tables of function pointers that sipcc maintains.

Adam pointed out that we don't really want this code to rot, but we could stop compiling and linking it in for mobile builds, where reducing code size is more important.

Apparently, sipcc runs to ~3M stripped.  There are probably significant savings to be gained.

Comment 1

[[:fabrice] Fabrice Desré]

Can someone look at that soon?

Comment 2

[Martin Thomson [:mt:]]

The people that are qualified to do this kind of surgery are both small in number and oversubscribed.  :bwc is already making changes that should help with runtime size by removing threads (bug ?).  I've put this on the agenda for our next meeting to discuss moving the priority up a little.

Comment 3

[Byron Campen [:bwc]]

The prototype patch for the threading work is at bug 991037; the patch is still ugly, and hard to make less ugly; we still need to service sipcc's queues either async on the same thread, or wait until the post into the message queue returns up to a certain level, since there are places in the code that deadlock or spin forever if we just do it right away. I'm pretty sure the cleanest way to proceed is to introduce an async dispatch (based on runnable_utils) after each post to a sipcc message queue, otherwise we need to manually feed sipcc cycles every time we _think_ we've done something that might ultimately (40 stack frames later) post something to a queue.

Comment 4

[Byron Campen [:bwc]]

Preventing compilation of sources won't help here, since we actually need all the sources we compile now. An awful lot of this code is gone now, but there is more to do in bug 1112737 and bug 1144963.