From sacadmin Fri Oct 5 11:16:56 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95IGuTv005068; Fri, 5 Oct 2007 11:16:56 -0700 (PDT) Received: (from plocher@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l95IGuO1005064; Fri, 5 Oct 2007 11:16:56 -0700 (PDT) Date: Fri, 5 Oct 2007 11:16:56 -0700 (PDT) From: John Plocher Message-Id: <200710051816.l95IGuO1005064@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Integrate libevent into Solaris [PSARC/2007/580 FastTrack] Status: RO Content-Length: 616 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Integrate libevent into Solaris 1.2. Name of Document Author/Supplier: Author: Prakash Sangappa 1.3 Date of This Document: 05 October, 2007 4. Technical Description Placeholder for memcached's dependency (see LSARC 2007/385 Memcached) SPEC TBD 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From bart.smaalders@Sun.COM Thu Oct 18 18:33:56 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9J1Xu5i000720 for ; Thu, 18 Oct 2007 18:33:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9J1UXBi010646; Thu, 18 Oct 2007 18:30:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400C0NXIXVK00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 18:30:33 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ400CHUXIW0900@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 18:30:32 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9J1UWrt299478; Fri, 19 Oct 2007 01:30:32 +0000 (GMT) Date: Thu, 18 Oct 2007 18:27:00 -0700 From: Bart Smaalders Subject: PSARC/2007/580 Integrate libevent into Solaris To: PSARC-EXT@Sun.COM Cc: prakash sangappa , John Plocher Message-id: <471807E4.9070702@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Ac/2XCsJeAsCdQ+CPZdftw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 17686 This is a multi-part message in MIME format. --Boundary_(ID_Ac/2XCsJeAsCdQ+CPZdftw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I'm sponsoring the attached arc case (libevent-arc.txt) for Prakash Sangappa. The requested release binding is patch/micro, and the case times out next Wednesday. I will place these materials in the case directory if it is chgrp'd to sac. = Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts --Boundary_(ID_Ac/2XCsJeAsCdQ+CPZdftw) Content-type: text/plain; name=libevent-arc.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=libevent-arc.txt 1. Introduction 1.1. Project/Component Working Name: libevent-1.3e 1.2. Name of Document Author/Supplier: Author: Prakash Sangappa. 1.3 Date of This Document: Sep 25 2007 4. Technical Description Summary This project integrates libevent-1.3e into Solaris This project requests a micro/patch binding. 4.1 Details Libevent is an open source event notifications library. The libevent API provides a mechanism to execute a callback function when specified events occurs on a file descriptor or after a timeout. Libevent API abstracts out the event notification mechanism it uses on an operating system, enabling portable application development. It uses the most efficient event notification mechanism available on an operating system. It currently supports /dev/poll, kqueues(2) available on BSD, select(2), poll(2), epoll(4) and Event Ports available in Solaris. On Solaris, by default, it uses Event Ports. It is possible to disable support for any of these event notification mechanism by setting the relevant environment variable. This is documented in the man page. In addition, libevent implements interfaces that provide additional functionality for embedding an event driven http server and buffered events. It also supports callbacks due to signals or regular timeouts. These interfaces are also documented in the man pages. Libevent has been developed and maintained by Nick Mathewson and Niels Provos - webpage http://monkey.org/~provos/libevent. Many applications already use libevent. The list of applications that use libevent currently are listed on the above web page. 4.2 Interface description All interfaces that libevent provides are 'Uncommitted'. The man page documentation of event(3) describes the interfaces. A formatted version of the man page documentation is included in the case directory. 4.3 Deliverables /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 /usr/include/evhttp.h /usr/include/event.h /usr/share/man/man3/event.3 64 bit libraries:- /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/sparc64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/sparc64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 5. References http://monkey.org/~provos/libevent. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack --Boundary_(ID_Ac/2XCsJeAsCdQ+CPZdftw) Content-type: application/x-troff-man; name=event3.man Content-transfer-encoding: 7bit Content-disposition: inline; filename=event3.man EVENT(3) UNIX Programmer's Manual EVENT(3) NAME event_init, event_dispatch, event_loop, event_loopexit, event_set, event_base_dispatch, event_base_loop, event_base_loopexit, event_base_set, event_base_free, event_add, event_del, event_once, event_base_once, event_pending, event_initialized, event_priority_init, event_priority_set, evtimer_set, evtimer_add, evtimer_del, evtimer_pending, evtimer_initialized, signal_set, signal_add, signal_del, signal_pending, signal_initialized, bufferevent_new, bufferevent_free, bufferevent_write, bufferevent_write_buffer, bufferevent_read, bufferevent_enable, bufferevent_disable, bufferevent_settimeout, bufferevent_base_set, evbuffer_new, evbuffer_free, evbuffer_add, evbuffer_add_buffer, evbuffer_add_printf, evbuffer_add_vprintf, evbuffer_drain, evbuffer_write, evbuffer_read, evbuffer_find, evbuffer_readline, evhttp_start, evhttp_free - execute a function when a specific event occurs SYNOPSIS event_init(void) event_dispatch(void) event_loop(int, flags) event_loopexit(struct, timeval, *tv) event_set(struct, event, *ev, int, fd, short, event) event_base_dispatch(struct, event_base, *base) event_base_loop(struct, event_base, *base, int, flags) event_base_loopexit(struct, event_base, *base, struct, timeval, *tv) event_base_set(struct, event_base, *base, struct, event, *) event_base_free(struct, event_base, *base) event_add(struct, event, *ev, struct, timeval, *tv) event_del(struct, event, *ev) event_once(int, fd, short, event, void, (*fn)(int,, short,) event_base_once(struct, event_base, *base, int, fd, short, event) event_pending(struct, event, *ev, short, event, struct, timeval) event_initialized(struct, event, *ev) event_priority_init(int, npriorities) event_priority_set(struct, event, *ev, int, priority) evtimer_set(struct, event, *ev, void, (*fn)(int,, short,, void) evtimer_add(struct, event, *ev, struct, timeval, *) evtimer_del(struct, event, *ev) evtimer_pending(struct, event, *ev, struct, timeval, *tv) evtimer_initialized(struct, event, *ev) signal_set(struct, event, *ev, int, signal, void, (*fn)(int,) signal_add(struct, event, *ev, struct, timeval, *) signal_del(struct, event, *ev) signal_pending(struct, event, *ev, struct, timeval, *tv) signal_initialized(struct, event, *ev) bufferevent_new(int, fd, evbuf- fercb, readcb, evbuffercb, writecb, everrorcb) bufferevent_free(struct, bufferevent, *bufev) bufferevent_write(struct, bufferevent, *bufev, void, *data, size_t, size) bufferevent_write_buffer(struct, bufferevent, *bufev, struct, evbuffer, *buf) bufferevent_read(struct, bufferevent, *bufev, void, *data, size_t, size) bufferevent_enable(struct, buf- ferevent, *bufev, short, event) bufferevent_disable(struct, bufferevent, *bufev, short, event) bufferevent_settimeout(struct, bufferevent, *bufev, int, timeout_read, int, timeout_write) bufferevent_base_set(struct, event_base, *base, struct, bufferevent, *bufev) evbuffer_new(void) evbuffer_free(struct, evbuffer, *buf) evbuffer_add(struct, evbuffer, *buf, const, void, *data, size_t) evbuffer_add_buffer(struct, evbuffer, *dst, struct, evbuffer, *src) evbuffer_add_printf(struct, evbuffer, *buf, const, char, *fmt, ...) evbuffer_add_vprintf(struct, evbuffer, *buf, const, char, *fmt, va_list) evbuffer_drain(struct, evbuffer, *buf, size_t, size) evbuffer_write(struct, evbuffer, *buf, int, fd) evbuffer_read(struct, evbuffer, *buf, int, fd, int, size) evbuffer_find(struct, evbuffer, *buf, const, u_char, *data, size_t) evbuffer_readline(struct, evbuffer, *buf) evhttp_start(const, char, *ad- dress, u_short, port) evhttp_free(struct, evhttp*, http) DESCRIPTION The event API provides a mechanism to execute a function when a specific event on a file descriptor occurs or after a given time has passed. The event API needs to be initialized with event_init() before it can be used. In order to process events, an application needs to call event_dispatch(). This function only returns on error, and should re- place the event core of the application program. In order to avoid races in signal handlers, the event API provides two variables: event_sigcb and event_gotsig. A signal handler sets event_gotsig to indicate that a signal has been received. The applica- tion sets event_sigcb to a callback function. After the signal handler sets event_gotsig, event_dispatch will execute the callback function to process received signals. The callback returns 1 when no events are re- gistered any more. It can return -1 to indicate an error to the event library, causing event_dispatch() to terminate with errno set to EINTR. The event_loop function provides an interface for single pass execution of pending events. The flags EVLOOP_ONCE and EVLOOP_NONBLOCK are recog- nized. The event_loopexit function allows the loop to be terminated after some amount of time has passed. The parameter indicates the time after which the loop should terminate. It is the responsibility of the caller to provide these functions with pre-allocated event structures. The function event_set() prepares the event structure to be used in fu- ture calls to event_add() and event_del(). The event will be prepared to call the function specified by the argument with an argument indicating the file descriptor, a argument indicating the type of event, and a argu- ment given in the argument. The indicates the file descriptor that should be monitored for events. The events can be either EV_READ, EV_WRITE, or both, indicating that an application can read or write from the file descriptor respectively without blocking. The function will be called with the file descriptor that triggered the event and the type of event which will be either EV_TIMEOUT, EV_SIGNAL, EV_READ, or EV_WRITE. The additional flag EV_PERSIST makes an event_add() persistent until event_del() has been called. Once initialized, the structure can be used repeatedly with event_add() and event_del() and does not need to be reinitialized unless the function called and/or the argument to it are to be changed. However, when an structure has been added to libevent using event_add() the structure must persist until the event occurs (assuming is not set) or is removed using event_del(). You may not reuse the same structure for multiple monitored descriptors; each descriptor needs its own The function event_add() schedules the execution of the event when the event specified in event_set() occurs or in at least the time specified in the If is no timeout occurs and the function will only be called if a matching event occurs on the file descriptor. The event in the argument must be already initialized by event_set() and may not be used in calls to event_set() until it has timed out or been removed with event_del(). If the event in the argument already has a scheduled timeout, the old timeout will be replaced by the new one. The function event_del() will cancel the event in the argument If the event has already executed or has never been added the call will have no effect. The function event_once() is similar to event_set(). However, it schedules a callback to be called exactly once and does not require the caller to prepare an structure. This function supports and The event_pending() function can be used to check if the event specified by is pending to run. If EV_TIMEOUT was specified and is not the expira- tion time of the event will be returned in The event_initialized() macro can be used to check if an event has been initialized. The functions evtimer_set(), evtimer_add(), evtimer_del(), evtimer_initialized(), and evtimer_pending() are abbreviations for common situations where only a timeout is required. The file descriptor passed will be -1, and the event type will be EV_TIMEOUT. The functions signal_set(), signal_add(), signal_del(), signal_initialized(), and signal_pending() are abbreviations. The event type will be a persistent EV_SIGNAL. That means signal_set() adds EV_PERSIST. It is possible to disable support for epoll, kqueue, devpoll, poll or select by setting the environment variable EVENT_NOEPOLL, EVENT_NOKQUEUE, EVENT_NODEVPOLL, EVENT_NOPOLL or EVENT_NOSELECT, respectively. By set- ting the environment variable EVENT_SHOW_METHOD, libevent displays the kernel notification method that it uses. EVENT PRIORITIES By default libevent schedules all active events with the same priority. However, sometimes it is desirable to process some events with a higher priority than others. For that reason, libevent supports strict priority queues. Active events with a lower priority are always processed before events with a higher priority. The number of different priorities can be set initially with the event_priority_init() function. This function should be called before the first call to event_dispatch(). The event_priority_set() function can be used to assign a priority to an event. By default, libevent as- signs the middle priority to all events unless their priority is expli- citly set. THREAD SAFE EVENTS Libevent has experimental support for thread-safe events. When initial- izing the library via event_init(), an event base is returned. This event base can be used in conjunction with calls to event_base_set(), event_base_dispatch(), event_base_loop(), event_base_loopexit(), bufferevent_base_set() and event_base_free(). event_base_set() should be called after preparing an event with event_set(), as event_set() assigns the provided event to the most recently created event base. bufferevent_base_set() should be called after preparing a bufferevent with bufferevent_new(). event_base_free() should be used to free memory associated with the event base when it is no longer needed. BUFFERED EVENTS libevent provides an abstraction on top of the regular event callbacks. This abstraction is called a buffered event. A buffered event provides input and output buffers that get filled and drained automatically. The user of a buffered event no longer deals directly with the IO, but in- stead is reading from input and writing to output buffers. A new bufferevent is created by bufferevent_new(). The parameter speci- fies the file descriptor from which data is read and written to. This file descriptor is not allowed to be a pipe(2). The next three parame- ters are callbacks. The read and write callback have the following form: (*cb)(struct, bufferevent, *bufev, void, *arg). The error callback has the following form: (*cb)(struct, bufferevent, *bufev, short, what, void, *arg) The argument is specified by the fourth parameter A pointer is returned on success, NULL on error. Both the read and the write call- back may be NULL. The error callback has to be always provided. Once initialized, the bufferevent structure can be used repeatedly with bufferevent_enable() and bufferevent_disable(). The flags parameter can be a combination of EV_READ and EV_WRITE. When read enabled the buf- ferevent will try to read from the file descriptor and call the read callback. The write callback is executed whenever the output buffer is drained below the write low watermark, which is 0 by default. The bufferevent_write() function can be used to write data to the file descriptor. The data is appended to the output buffer and written to the descriptor automatically as it becomes available for writing. bufferevent_write() returns 0 on success or -1 on failure. The bufferevent_read() function is used to read data from the input buffer, returning the amount of data read. If multiple bases are in use, bufferevent_base_set() must be called be- fore enabling the bufferevent for the first time. NON-BLOCKING HTTP SUPPORT libevent provides a very thin HTTP layer that can be used both to host an HTTP server and also to make HTTP requests. An HTTP server can be creat- ed by calling evhttp_start(). When the HTTP server is no longer used, it can be freed via evhttp_free(). To be notified of HTTP requests, a user needs to register callbacks with the HTTP server. This can be done by calling evhttp_set_cb(). The second argument is the URI for which a callback is being registered. The corresponding callback will receive an struct evhttp_request object that contains all information about the request. This section does not document all the possible function calls; please check event.h for the public interfaces. RETURN VALUES Upon successful completion event_add() and event_del() return 0. Other- wise, -1 is returned and the global variable errno is set to indicate the error. SEE ALSO kqueue(2), poll(2), select(2), evdns(3), timeout(9) HISTORY The event API manpage is based on the timeout(9) manpage by Artur Gra- bowski. The port of libevent to Windows is due to Michael A. Davis. Support for real-time signals is due to Taral. AUTHORS The event library was written by Niels Provos. BUGS This documentation is neither complete nor authoritative. If you are in doubt about the usage of this API then check the source code to find out how it works, write up the missing piece of documentation and send it to me for inclusion in this man page. --Boundary_(ID_Ac/2XCsJeAsCdQ+CPZdftw)-- From Mark.Carlson@sun.com Thu Oct 18 19:13:24 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9J2DOwi001271 for ; Thu, 18 Oct 2007 19:13:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9J2A1to019389; Thu, 18 Oct 2007 19:10:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400F01ZCO5R00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 19:10:00 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ400CZ7ZCN0A10@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 19:09:59 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9J29xTK028724; Fri, 19 Oct 2007 02:09:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ400801Z868A00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Thu, 18 Oct 2007 20:09:59 -0600 (MDT) Received: from MACsMAC.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ400IOTZCNVHD0@mail-amer.sun.com>; Thu, 18 Oct 2007 20:09:59 -0600 (MDT) Date: Thu, 18 Oct 2007 20:09:55 -0600 From: "Mark A. Carlson" Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <471807E4.9070702@Sun.COM> Sender: Mark.Carlson@sun.com To: Bart Smaalders Cc: PSARC-EXT@sun.com, prakash sangappa , John Plocher Message-id: <471811F3.2030806@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KvQGOStfE5B5o8j7vomLoA)" X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 2492 This is a multi-part message in MIME format. --Boundary_(ID_KvQGOStfE5B5o8j7vomLoA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT From the memcached LSARC case: ac-4 20q, #10.11: *Presumably /usr/local/lib/libevent-1.3b.so.1 will be somewhere else when the libevent case is done? * /Depends on libevent case which has not been filed. May make it part of this case. / So, I guess this is the separate fast track for the previous dependency, correct? -- mark Bart Smaalders wrote: > > I'm sponsoring the attached arc case (libevent-arc.txt) for > Prakash Sangappa. The requested release binding is patch/micro, > and the case times out next Wednesday. > > I will place these materials in the case directory if it is > chgrp'd to sac. > > = Bart > > ------------------------------------------------------------------------ > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org --Boundary_(ID_KvQGOStfE5B5o8j7vomLoA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT From the memcached LSARC case:
ac-4    20q, #10.11: Presumably /usr/local/lib/libevent-1.3b.so.1
    will be somewhere else when the libevent case is done?

Depends on libevent case which has not been filed.  May make
it part of this case.

So, I guess this is the separate fast track for the previous
dependency, correct?

-- mark

Bart Smaalders wrote:

I'm sponsoring the attached arc case (libevent-arc.txt) for
Prakash Sangappa.  The requested release binding is patch/micro,
and the case times out next Wednesday.

I will place these materials in the case directory if it is
chgrp'd to sac.

= Bart 


_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_KvQGOStfE5B5o8j7vomLoA)-- From bart.smaalders@sun.com Thu Oct 18 19:16:25 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9J2GPP1001287 for ; Thu, 18 Oct 2007 19:16:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9J2D29a036758; Thu, 18 Oct 2007 20:13:02 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400E07ZHPAR00@brm-avmta-1.central.sun.com>; Thu, 18 Oct 2007 20:13:01 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ4008Y3ZHOXG30@brm-avmta-1.central.sun.com>; Thu, 18 Oct 2007 20:13:00 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9J2D0Ya300210; Fri, 19 Oct 2007 02:13:00 +0000 (GMT) Date: Thu, 18 Oct 2007 19:09:29 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <471811F3.2030806@sun.com> To: "Mark A. Carlson" Cc: PSARC-EXT@sun.com, prakash sangappa , John Plocher Message-id: <471811D9.3030604@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <471811F3.2030806@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 487 Mark A. Carlson wrote: > From the memcached LSARC case: > ac-4 20q, #10.11: *Presumably /usr/local/lib/libevent-1.3b.so.1 > will be somewhere else when the libevent case is done? * > > /Depends on libevent case which has not been filed. May make > it part of this case. / > > So, I guess this is the separate fast track for the previous > dependency, correct? yes - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From carlsonj@phorcys.east.sun.com Fri Oct 19 05:46:20 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JCkJ63009710 for ; Fri, 19 Oct 2007 05:46:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9JCgYeM017469; Fri, 19 Oct 2007 20:42:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ500D0RSNB5E00@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Oct 2007 05:42:47 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ500AIDSNACHB0@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Oct 2007 05:42:46 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9JCgMe6007424; Fri, 19 Oct 2007 08:42:22 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9JCgMZ4007421; Fri, 19 Oct 2007 08:42:22 -0400 (EDT) Date: Fri, 19 Oct 2007 08:42:22 -0400 From: James Carlson Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <471807E4.9070702@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@Sun.COM, prakash sangappa , John Plocher Message-id: <18200.42542.490894.627099@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> Status: RO Content-Length: 1030 Bart Smaalders writes: > It is possible to disable support for any of these event notification > mechanism by setting the relevant environment variable. This is > documented in the man page. That's just frightening. This appears to mean that the internal design of the library can (in effect) be altered by the end user at run time. Any clue why this is a reasonable thing to include in this delivery? Is there any advantage to allowing the end user of an application linked to libevent to "tweak" the underlying mechanism? I can understand perhaps it when compiled with -DDEBUG, but it seems strange and potentially hazardous otherwise. > In addition, libevent implements interfaces that provide additional > functionality for embedding an event driven http server and buffered An http server? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From bart.smaalders@sun.com Fri Oct 19 09:19:39 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JGJcVw013324 for ; Fri, 19 Oct 2007 09:19:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9JGGCer024445; Fri, 19 Oct 2007 09:16:14 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600D0T2J1KD00@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 10:16:13 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ600BWD2IYKH10@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 10:16:10 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9JGGADD307100; Fri, 19 Oct 2007 16:16:10 +0000 (GMT) Date: Fri, 19 Oct 2007 09:12:38 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <18200.42542.490894.627099@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-EXT@sun.com, prakash sangappa , John Plocher Message-id: <4718D776.3030905@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <18200.42542.490894.627099@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1681 James Carlson wrote: > Bart Smaalders writes: >> It is possible to disable support for any of these event notification >> mechanism by setting the relevant environment variable. This is >> documented in the man page. > > That's just frightening. This appears to mean that the internal > design of the library can (in effect) be altered by the end user at > run time. > You mean like LD_LIBRARY_PATH to select an alternate malloc implementation, interpose audit libraries, and the like? Or change the default library search order w/ LD_CONFIG? Or to select the number of processors used w/ NCPU? > Any clue why this is a reasonable thing to include in this delivery? > Is there any advantage to allowing the end user of an application > linked to libevent to "tweak" the underlying mechanism? There's a long history in all sorts of places of modifying application behavior with environment variables. The selection of dispatching mechanism used internally inside libevent seems to be just yet another choice. Given the history of bugs in all the mechanisms available - /dev/poll, kqueues, epoll, etc, providing a mechanism to select a possibly less broken implementation doesn't seem that unusual. > > I can understand perhaps it when compiled with -DDEBUG, but it seems > strange and potentially hazardous otherwise. > >> In addition, libevent implements interfaces that provide additional >> functionality for embedding an event driven http server and buffered > > An http server? > As far as I know, this was removed from all but the man page. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From carlsonj@phorcys.east.sun.com Fri Oct 19 10:16:25 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JHGPTg015444 for ; Fri, 19 Oct 2007 10:16:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9JHCwc5010651; Fri, 19 Oct 2007 11:13:01 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600H0N55OS200@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 11:13:00 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ600BLJ55NKE60@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 11:12:59 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9JHCab5009081; Fri, 19 Oct 2007 13:12:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9JHCa6p009078; Fri, 19 Oct 2007 13:12:36 -0400 (EDT) Date: Fri, 19 Oct 2007 13:12:36 -0400 From: James Carlson Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <4718D776.3030905@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@sun.com, prakash sangappa , John Plocher Message-id: <18200.58756.524516.844769@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <18200.42542.490894.627099@gargle.gargle.HOWL> <4718D776.3030905@Sun.COM> Status: RO Content-Length: 2398 Bart Smaalders writes: > James Carlson wrote: > > Bart Smaalders writes: > >> It is possible to disable support for any of these event notification > >> mechanism by setting the relevant environment variable. This is > >> documented in the man page. > > > > That's just frightening. This appears to mean that the internal > > design of the library can (in effect) be altered by the end user at > > run time. > > > > You mean like LD_LIBRARY_PATH to select an alternate malloc > implementation, interpose audit libraries, and the like? Which, of course, has run many folks into trouble and thus has setuid safeguards as well as frequent "don't do this" warnings. > Or change > the default library search order w/ LD_CONFIG? Same issue. > Or to select the number > of processors used w/ NCPU? That seems a bit different, as it doesn't actually choose an different implementation. > > Any clue why this is a reasonable thing to include in this delivery? > > Is there any advantage to allowing the end user of an application > > linked to libevent to "tweak" the underlying mechanism? > > There's a long history in all sorts of places of modifying application > behavior with environment variables. The selection of dispatching > mechanism used internally inside libevent seems to be just yet another > choice. Given the history of bugs in all the mechanisms available - > /dev/poll, kqueues, epoll, etc, providing a mechanism to select > a possibly less broken implementation doesn't seem that unusual. I see. If the person integrating this library is adamant that preserving this "feature" really is the right thing to do on Solaris, I guess I'll back down. I'm not prepared to derail over it. It just doesn't seem wise to me. > > I can understand perhaps it when compiled with -DDEBUG, but it seems > > strange and potentially hazardous otherwise. > > > >> In addition, libevent implements interfaces that provide additional > >> functionality for embedding an event driven http server and buffered > > > > An http server? > > > As far as I know, this was removed from all but the man page. OK ... so that's not part of this project, right? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From prakash.sangappa@sun.com Fri Oct 19 13:20:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JKKLKd020200 for ; Fri, 19 Oct 2007 13:20:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9JKGnU9021936; Sat, 20 Oct 2007 04:16:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600A03DO04B00@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 14:16:48 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ6005TXDO0BT10@brm-avmta-1.central.sun.com>; Fri, 19 Oct 2007 14:16:48 -0600 (MDT) Received: from [129.146.228.98] (justforkicks.SFBay.Sun.COM [129.146.228.98]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9JKGl4w532362; Fri, 19 Oct 2007 13:16:47 -0700 (PDT) Date: Fri, 19 Oct 2007 13:12:36 -0700 From: Prakash Sangappa Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <18200.58756.524516.844769@gargle.gargle.HOWL> To: James Carlson Cc: Bart Smaalders , PSARC-EXT@sun.com, John Plocher Message-id: <47190FB4.2000900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <18200.42542.490894.627099@gargle.gargle.HOWL> <4718D776.3030905@Sun.COM> <18200.58756.524516.844769@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.4 (X11/20060701) Status: RO Content-Length: 2523 James Carlson wrote: > Bart Smaalders writes: > >> James Carlson wrote: >> >>> Bart Smaalders writes: >>> >>>> It is possible to disable support for any of these event notification >>>> mechanism by setting the relevant environment variable. This is >>>> documented in the man page. >>>> >>> That's just frightening. This appears to mean that the internal >>> design of the library can (in effect) be altered by the end user at >>> run time. >>> >>> >> You mean like LD_LIBRARY_PATH to select an alternate malloc >> implementation, interpose audit libraries, and the like? >> > > Which, of course, has run many folks into trouble and thus has setuid > safeguards as well as frequent "don't do this" warnings. > > >> Or change >> the default library search order w/ LD_CONFIG? >> > > Same issue. > > >> Or to select the number >> of processors used w/ NCPU? >> > > That seems a bit different, as it doesn't actually choose an different > implementation. > > >> > Any clue why this is a reasonable thing to include in this delivery? >> > Is there any advantage to allowing the end user of an application >> > linked to libevent to "tweak" the underlying mechanism? >> >> There's a long history in all sorts of places of modifying application >> behavior with environment variables. The selection of dispatching >> mechanism used internally inside libevent seems to be just yet another >> choice. Given the history of bugs in all the mechanisms available - >> /dev/poll, kqueues, epoll, etc, providing a mechanism to select >> a possibly less broken implementation doesn't seem that unusual. >> > > I see. If the person integrating this library is adamant that > preserving this "feature" really is the right thing to do on Solaris, > I guess I'll back down. I'm not prepared to derail over it. It just > doesn't seem wise to me. > Yes, we would like to keep this feature. > >>> I can understand perhaps it when compiled with -DDEBUG, but it seems >>> strange and potentially hazardous otherwise. >>> >>> >>>> In addition, libevent implements interfaces that provide additional >>>> functionality for embedding an event driven http server and buffered >>>> >>> An http server? >>> >>> >> As far as I know, this was removed from all but the man page. >> > > OK ... so that's not part of this project, right? > Yes, this will not be included in the libevent library that gets delivered in Solaris. -Prakash. From roland.mainz@nrubsig.org Fri Oct 19 18:56:13 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9K1uCuK026120 for ; Fri, 19 Oct 2007 18:56:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9K1qhvc001331; Sat, 20 Oct 2007 02:52:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600401T7WZW00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Oct 2007 18:52:44 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ600FWCT7V8J70@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Oct 2007 18:52:43 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9K1qhon029427; Sat, 20 Oct 2007 01:52:43 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay14i.sun.com with ESMTP id BT-MMP-526958; Sat, 20 Oct 2007 01:52:43 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp12es.sun.com with ESMTP id BT-MMP-144631; Sat, 20 Oct 2007 01:52:42 +0000 (Z) Received: from mail-in-10.arcor-online.net ([151.189.21.50] [151.189.21.50]) by relay1ib.sun.com with ESMTP id BT-MMP-1888719; Sat, 20 Oct 2007 01:52:42 +0000 (Z) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 1DC5E1F5E4D; Sat, 20 Oct 2007 03:52:37 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 0CBB8ABAAB; Sat, 20 Oct 2007 03:52:37 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-239-111.pools.arcor-ip.net [84.58.239.111]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 4F4A98C477; Thu, 15 Feb 2007 13:17:50 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l9K1qSv2002027; Sat, 20 Oct 2007 03:52:28 +0200 (CEST) Date: Sat, 20 Oct 2007 03:52:27 +0200 From: Roland Mainz Subject: Re: PSARC/2007/580 Integrate libevent into Solaris Sender: gisburn@jupiterb48.nrubsig.org To: Bart Smaalders Cc: PSARC-EXT@sun.com, prakash sangappa , John Plocher Message-id: <47195F5B.327308B@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 23:05:57 2007 on mail-in-12.arcor-online.net X-Virus-Status: Clean References: <471807E4.9070702@Sun.COM> Status: RO Content-Length: 1041 Bart Smaalders wrote: > > I'm sponsoring the attached arc case (libevent-arc.txt) for > Prakash Sangappa. The requested release binding is patch/micro, > and the case times out next Wednesday. > > I will place these materials in the case directory if it is > chgrp'd to sac. [snip] > 4.3 Deliverables > > /usr/lib/libevent.so.1.0.3 > /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 > /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 > /usr/include/evhttp.h > /usr/include/event.h > /usr/share/man/man3/event.3 > > 64 bit libraries:- > > /usr/lib/sparc64/libevent.so.1.0.3 > /usr/lib/sparc64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 > /usr/lib/sparc64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 Erm... shouldn't this go into /usr/lib/sparcv9/ ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From prakash.sangappa@sun.com Mon Oct 22 08:22:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MFMZ4S008203 for ; Mon, 22 Oct 2007 08:22:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9MFIKRG015251; Mon, 22 Oct 2007 08:18:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQB00C0BJUKM600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Oct 2007 08:18:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQB00M19JUJREC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Oct 2007 08:18:19 -0700 (PDT) Received: from [10.7.251.81] (punchin-client-10-7-251-81.SFBay.Sun.COM [10.7.251.81]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MFIIUM299985; Mon, 22 Oct 2007 08:18:19 -0700 (PDT) Date: Mon, 22 Oct 2007 08:18:18 -0700 From: prakash sangappa Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <47195F5B.327308B@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , PSARC-EXT@sun.com, John Plocher Message-id: <471CBF3A.6050906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <47195F5B.327308B@nrubsig.org> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1723 Roland Mainz wrote: > Bart Smaalders wrote: > >> I'm sponsoring the attached arc case (libevent-arc.txt) for >> Prakash Sangappa. The requested release binding is patch/micro, >> and the case times out next Wednesday. >> >> I will place these materials in the case directory if it is >> chgrp'd to sac. >> > [snip] > >> 4.3 Deliverables >> >> /usr/lib/libevent.so.1.0.3 >> /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 >> /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 >> /usr/include/evhttp.h >> /usr/include/event.h >> /usr/share/man/man3/event.3 >> >> 64 bit libraries:- >> >> /usr/lib/sparc64/libevent.so.1.0.3 >> /usr/lib/sparc64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 >> /usr/lib/sparc64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 >> > > Erm... shouldn't this go into /usr/lib/sparcv9/ ? > Yes, The updated list of deliverables is. /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 /usr/include/event.h /usr/share/man/man3/event.3 64 bit libraries:- /usr/lib/sparcv9/libevent.so.1.0.3 /usr/lib/sparcv9/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/sparcv9/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 Note no '/usr/include/evhttp.h' since the http server is not included. -Prakash. > ---- > > Bye, > Roland > > From prakash.sangappa@sun.com Mon Oct 22 08:38:17 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MFcGgD008298 for ; Mon, 22 Oct 2007 08:38:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9MFYjHu014368; Mon, 22 Oct 2007 16:34:46 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQB00C0BKLWWE00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Oct 2007 08:34:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQB00CV1KLWCR20@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Oct 2007 08:34:44 -0700 (PDT) Received: from [10.7.251.81] (punchin-client-10-7-251-81.SFBay.Sun.COM [10.7.251.81]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MFYhhe302720; Mon, 22 Oct 2007 08:34:43 -0700 (PDT) Date: Mon, 22 Oct 2007 08:34:43 -0700 From: prakash sangappa Subject: Re: PSARC/2007/580 Integrate libevent into Solaris In-reply-to: <47195F5B.327308B@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , PSARC-EXT@sun.com, John Plocher Message-id: <471CC313.3050606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471807E4.9070702@Sun.COM> <47195F5B.327308B@nrubsig.org> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1706 Roland Mainz wrote: > Bart Smaalders wrote: > >> I'm sponsoring the attached arc case (libevent-arc.txt) for >> Prakash Sangappa. The requested release binding is patch/micro, >> and the case times out next Wednesday. >> >> I will place these materials in the case directory if it is >> chgrp'd to sac. >> > [snip] > >> 4.3 Deliverables >> >> /usr/lib/libevent.so.1.0.3 >> /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 >> /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 >> /usr/include/evhttp.h >> /usr/include/event.h >> /usr/share/man/man3/event.3 >> >> 64 bit libraries:- >> >> /usr/lib/sparc64/libevent.so.1.0.3 >> /usr/lib/sparc64/libevent.so.1 -> /usr/lib/sparc64/libevent.so.1.0.3 >> /usr/lib/sparc64/libevent.so -> /usr/lib/sparc64/libevent.so.1.0.3 >> > > Erm... shouldn't this go into /usr/lib/sparcv9/ ? > Yes, The updated list of deliverables is. /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so.1 -> /usr/lib/libevent.so.1.0.3 /usr/lib/libevent.so -> /usr/lib/libevent.so.1.0.3 /usr/include/event.h /usr/share/man/man3/event.3 64 bit libraries:- /usr/lib/sparcv9/libevent.so.1.0.3 /usr/lib/sparcv9/libevent.so.1 -> /usr/lib/sparcv9/libevent.so.1.0.3 /usr/lib/sparcv9/libevent.so -> /usr/lib/sparcv9/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so.1 -> /usr/lib/amd64/libevent.so.1.0.3 /usr/lib/amd64/libevent.so -> /usr/lib/amd64/libevent.so.1.0.3 Note no '/usr/include/evhttp.h' since the http server is not included. -Prakash. > ---- > > Bye, > Roland > > From bart.smaalders@Sun.COM Mon Nov 12 09:18:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lACHIE1t012593 for ; Mon, 12 Nov 2007 09:18:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lACHIBxY029131 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@Sun.COM>; Mon, 12 Nov 2007 17:18:13 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRE00F03LEB1O00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Mon, 12 Nov 2007 09:18:11 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRE00F30LEA0900@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Mon, 12 Nov 2007 09:18:11 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lACHIAS6427135 for ; Mon, 12 Nov 2007 17:18:10 +0000 (GMT) Date: Mon, 12 Nov 2007 09:14:18 -0800 From: Bart Smaalders Subject: PSARC/2007/580 Integrate libevent into Solaris To: PSARC-EXT@Sun.COM Message-id: <473889EA.7040508@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 166 This fasttrack was approved some time ago on 10/24/2007. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts