On May 16, 2014, at 2:18 PM, James Peach wrote:
> Does anyone have any concerns about bringing in doxygen as a documentation
> build dependency?
As long as it’s optional, that seems fine. I doubt many (any?) people build the
docs, in fact, I still think we should stop building some of our doc
On May 16, 2014, at 2:29 PM, Alan M. Carroll
wrote:
> I've been thinking about some of the SPDY issues that have come up and have a
> couple of ideas.
>
> First, the SPDY SM is really a client session. It handles input from a client
> socket and drives the transactions through the system, wi
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/82#issuecomment-43387181
You will need to rebase onto current master. Please update doc/checkvers.py
to check for the updated dependencies. Please update contrib/manifests/* to
install the a
Hi all,
I'm proposing a new API, TSVConnFdCreate.
TSVConn TSVConnFdCreate(int fd)
TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that wraps
that file descriptor. The file descriptor must be a connected socket. The
resulting TSVConn can be used with the standard TS
On May 16, 2014, at 11:28 AM, Bardwell, William wrote:
> I love it...in fact I already implemented this against 3.2.X for a similar
> use. I called it TSVConnFromFdCreate(), I had it taking a mutex (that could
> be NULL) as well, but not sure if that is really needed.
I think the mutex might
I've been thinking about some of the SPDY issues that have come up and have a
couple of ideas.
First, the SPDY SM is really a client session. It handles input from a client
socket and drives the transactions through the system, without interacting
(directly) with any of the origin servers or th
Does anyone have any concerns about bringing in doxygen as a documentation
build dependency?
On May 13, 2014, at 12:22 PM, jablko wrote:
> GitHub user jablko opened a pull request:
>
>https://github.com/apache/trafficserver/pull/85
>
>docs: Add Doxygen group commands to API sections
>
I love it...in fact I already implemented this against 3.2.X for a similar use.
I called it TSVConnFromFdCreate(), I had it taking a mutex (that could be
NULL) as well, but not sure if that is really needed. (I liked the "From" part
of the name to make it clear that it wasn't making and Fd ins
Phil Sorber writes:
>
> I'd like to propose that we pull libck into our tree and use it to replace
> some of our stuff like the freelist, ink_atomic_list and hash tables.
>
> http://concurrencykit.org/
>
> Right now there are not enough distro's to make just linking against system
> libs feasi
On May 16, 2014, at 9:30 AM, James Peach wrote:
> On May 15, 2014, at 12:57 PM, Leif Hedstrom wrote:
>
>> Hi all,
>>
>> I’d like to remove the existing traffic_shell command. This is one of two
>> remaining TCL places, and as far as I know, this is of little use. Now, a
>> significant porti
On May 15, 2014, at 8:07 AM, James Peach wrote:
> Hi all,
>
> I'm proposing a new API, TSVConnFdCreate.
>
> TSVConn TSVConnFdCreate(int fd)
>
> TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that
> wraps that file descriptor. The file descriptor must be a connected
On May 15, 2014, at 12:57 PM, Leif Hedstrom wrote:
> Hi all,
>
> I’d like to remove the existing traffic_shell command. This is one of two
> remaining TCL places, and as far as I know, this is of little use. Now, a
> significant portion, but not all, of traffic_shell has been reimplemented as
Hi all,
I’d like to remove the existing traffic_shell command. This is one of two
remaining TCL places, and as far as I know, this is of little use. Now, a
significant portion, but not all, of traffic_shell has been reimplemented as a
Perl script. I’m hoping this is an adequate tool to at least
Hi Phil,
Can you give me some more details on how the call to hwloc_get_nbobjs_by_type()
could return 0? I can see how a system could have 0 NUMA nodes, but that case
falls through to sockets, and I would have thought that every platform would
have at least 1 socket.
Additionally, I think that
14 matches
Mail list logo
