Hi folks
I've been working on integrating 2.0.6-rc into the Open MPI code base and ran
across an issue. You distribute an aclocal.m4 that was generated by libtool
2.2.6b, and you don't whack it at the beginning of autogen.sh. Thus, those of
us who have updated to libtool 2.2.10 get an error.
I
Sorry about the typo - yes, it is indeed -ivf
On Sep 3, 2010, at 10:08 AM, Nick Mathewson wrote:
> On Fri, Sep 3, 2010 at 11:59 AM, Ralph Castain wrote:
>> Hi folks
>>
>> I've been working on integrating 2.0.6-rc into the Open MPI code base and
>> ran ac
Hi folks
As stated in a prior note, I'm working on integrating libevent 2.0 with Open
MPI. We actually carry a copy of your code as part of our distribution
(respecting all copyright requirements) for two reasons: (a) portability (to
ensure that someone building OMPI on their machine has the sa
On Sep 7, 2010, at 9:35 AM, Nick Mathewson wrote:
> Hi, Ralph!
>
> On Tue, Sep 7, 2010 at 11:04 AM, Ralph Castain wrote:
> [...]
>> (b) we need to modify it somewhat to get things working correctly across the
>> broad range of our installed base.
>
> Any chanc
Hi folks
Continuing the discussion re pushing some of Open MPI's experiences
upstream, I have attached our opal_setup_libevent.m4 script for building
libevent as part of OMPI. Note that the comments describe several scenarios
where the existing libevent tests aren't quite adequate for detecting wh
Unfortunately, this won't solve the problem in a portable way as pragma is
purely a GCC extension. Many of our users build with Intel and other compilers,
so we need a more generalized solution.
I have asked the OMPI developers who did the visibility work if they could
either share their genera
On Mon, Sep 13, 2010 at 8:24 PM, Nick Mathewson wrote:
> On Tue, Sep 7, 2010 at 2:31 PM, Ralph Castain wrote:
> > Hi folks
> > Continuing the discussion re pushing some of Open MPI's experiences
> > upstream, I have attached our opal_setup_libevent.m4 script for building
Hi folks
I'm getting a warning message when compiling 2.0.7rc:
In file included from ../../opal/event/libevent/event-internal.h:37, from
opal_event.c:44: ../../opal/event/libevent/minheap-internal.h: In function
'min_heap_erase':
This is the offending line:
if (((unsigned int)-1) != e->ev_timeo
Hi folks
I apologize for the ignorance - I'm sure this is something simple that I'm
overlooking.
I built libevent 2.0.7rc with the default configuration, so I did -not- specify
--disable-debug. It is my understanding that the debug code is therefore built.
I have confirmed that this is the cas
On Oct 12, 2010, at 8:59 AM, Nick Mathewson wrote:
> On Tue, Oct 12, 2010 at 10:55 AM, Ralph Castain wrote:
>> Hi folks
>>
>> I apologize for the ignorance - I'm sure this is something simple that I'm
>> overlooking.
>>
>> I built libevent
(_EVENT_LOG_DEBUG, NULL, fmt, ap);
va_end(ap);
I then created OMPI API to set the debug output flag - imagine you would need
to do something similar in libevent itself.
HTH
Ralph
On Oct 12, 2010, at 9:53 AM, Nick Mathewson wrote:
> On Tue, Oct 12, 2010 at 11:50 AM, Ralph Castain wr
hoping to do that around 2.0.9-(rc/stable),
> which I hope to have our in a month or so.
>
> I'm going to try to get more http bugfixes in over the next month. My
> next mail will be about how to make sure your favorite http bug is one
> of the ones that gets attention.
On Oct 14, 2010, at 9:26 PM, Nick Mathewson wrote:
> On Thu, Oct 14, 2010 at 11:21 PM, Ralph Castain wrote:
>> Hi Nick
>>
>> FWIW: the latest autoconf release (2.68) includes a number of changes to
>> autoconf that causes libevent's configure logic to sp
Hi folks
I successfully updated our libevent integration in Open MPI, but have
encountered a problem with one use-case that used to work and now doesn't.
Before proceeding to devise a fix, I just wanted to confirm that I accurately
understand the issue.
The problem arises from this scenario:
On Oct 23, 2010, at 9:42 AM, Nick Mathewson wrote:
> On Sat, Oct 23, 2010 at 5:14 AM, Ralph Castain wrote:
>> Hi folks
>>
>> I successfully updated our libevent integration in Open MPI, but have
>> encountered a problem with one use-case that used to work
On Oct 23, 2010, at 9:42 AM, Nick Mathewson wrote:
> On Sat, Oct 23, 2010 at 5:14 AM, Ralph Castain wrote:
>> Hi folks
>>
>> I successfully updated our libevent integration in Open MPI, but have
>> encountered a problem with one use-case that used to work
On Oct 23, 2010, at 12:40 PM, Ralph Castain wrote:
>
> On Oct 23, 2010, at 9:42 AM, Nick Mathewson wrote:
>
>> On Sat, Oct 23, 2010 at 5:14 AM, Ralph Castain wrote:
>>> Hi folks
>>>
>>> I successfully updated our libevent integration in Open MPI, bu
asking libevent to change something.
HTH
Ralph
On Oct 26, 2010, at 8:16 PM, Nick Mathewson wrote:
> On Sat, Oct 23, 2010 at 5:14 AM, Ralph Castain wrote:
>> Hi folks
>>
>> I successfully updated our libevent integration in Open MPI, but have
>> encountered a problem
Just wondering: would it make sense to provide a libevent API for this?
I ask because proper shutdown is important to a number of us, and it seems a
shame that we all have to independently sprinkle the code throughout our
programs wherever sockets are used. On the surface, at least, it would app
Hi folks
I'm running into a problem that probably results from my ignorance. So I
figured I would ask if someone can tell me what I'm doing wrong.
I have a thread that loops the event library with the following call:
events += event_loop(mca_oob_tcp_component.event_base, EVLOOP_ONCE);
On Nov 9, 2010, at 9:03 PM, Nick Mathewson wrote:
> On Tue, Nov 9, 2010 at 3:28 PM, Ralph Castain wrote:
>> Hi folks
>>
>> I'm running into a problem that probably results from my ignorance. So I
>> figured I would ask if someone can tell me what I'm doi
On Nov 9, 2010, at 9:57 PM, Nick Mathewson wrote:
> On Tue, Nov 9, 2010 at 11:47 PM, Ralph Castain wrote:
>>
>> On Nov 9, 2010, at 9:03 PM, Nick Mathewson wrote:
> [...]
>>> So I'm assuming that you've got all the threading callbacks set up
>>> (pr
non-volatile data.
Any suggestions would be greatly appreciated!
Ralph
event-threads.c
Description: Binary data
On Nov 10, 2010, at 10:20 AM, Nick Mathewson wrote:
> On Wed, Nov 10, 2010 at 9:58 AM, Ralph Castain wrote:
>>
>> On Nov 9, 2010, at 9:57 PM, Nick Mathewson wrote:
>&g
an 2007, and the email archives don't quite go back that far -
leaving the link broken. Any chance you have the referenced example somewhere
and can restore the link? It sounded like he addresses a lot of these issues.
On Nov 11, 2010, at 8:34 PM, Nick Mathewson wrote:
> On Thu, Nov 11, 2
to determine what/how things are done is always difficult.
On Nov 12, 2010, at 9:29 PM, Nick Mathewson wrote:
> On Fri, Nov 12, 2010 at 10:47 AM, Ralph Castain wrote:
>> Hi Nick
>>
>> Appreciate the help. Shame on me for the buglet re open.
>>
>> Using your rev
And I have a Windows and Solaris compile patch for you too :-)
My bad - I'm behind in getting it to you.
On Nov 30, 2010, at 7:41 AM, Kelly Brock wrote:
> Great news but the iocp fix needs a minor fix:
>
> Line 618 & 619 need to be modified as follows:
> setsockopt(sock, SOL_SOCK
Frankly, having fought the test vs user-configure battle many times, there
comes a point where the user bears some responsibility. This strikes me as one
of those times.
For us, at least, creating another startup delay while libevent probes timers
would be more than annoying. It is completely r
Hi folks
I'm trying to use libevent 2.0.13 with priorities, and am having a problem when
signal events are defined. Basically, this is what I do:
1. create an event base
2. call event_base_priority_init(base, 8)
3. event_assign(&event, base, SIGTERM, EV_SIGNAL|EV_PERSIST, cbfunc, &event)
4. e
lse I need to
set to get diagnostic output from libevent?
Haven't had any luck with valgrind catching something, but will try some other
methods.
Thanks
Ralph
On Jan 4, 2012, at 10:28 AM, Nick Mathewson wrote:
> On Tue, Jan 3, 2012 at 6:45 PM, Ralph Castain wrote:
>> Hi folks
>&
nary data
On Jan 5, 2012, at 10:28 AM, Nick Mathewson wrote:
> On Wed, Jan 4, 2012 at 2:50 PM, Ralph Castain wrote:
>> Hmmm...Well, your program works fine for me too, and I haven't succeeded in
>> making it crash, so I suspect it is a bug in my code (which is what I
>&
y this situation? Is activating a newly-defined event
during an event callback not permitted?
Thanks
Ralph
evpri-test.c
Description: Binary data
On Jan 5, 2012, at 8:01 PM, Ralph Castain wrote:
> Well, after playing around a bit, I did finally manage to recreate the
> scenario in my main
*and* activate it
there.
However, it is okay to assign the event during the callback so long as I don't
activate it until after I return.
Seems a little strange to me - is this the intended behavior?
On Jan 6, 2012, at 2:09 AM, Ralph Castain wrote:
> I've pursued this further,
On Jan 6, 2012, at 7:02 AM, Nick Mathewson wrote:
> On Fri, Jan 6, 2012 at 7:24 AM, Ralph Castain wrote:
>> If it helps, I have now confirmed that I *can* activate the t2 event during
>> the t1func callback in my example *provided* I called event_assign on it
>&
.
Thanks again
Ralph
On Jan 6, 2012, at 8:15 AM, Ralph Castain wrote:
>
> On Jan 6, 2012, at 7:02 AM, Nick Mathewson wrote:
>
>> On Fri, Jan 6, 2012 at 7:24 AM, Ralph Castain wrote:
>>> If it helps, I have now confirmed that I *can* activate the t2 event during
>>
ng else is going on here, or if there is a bug in libevent itself?
Thanks
Ralph
On Jan 6, 2012, at 12:47 PM, Ralph Castain wrote:
> Afraid I'm going to have to eat my words here, Nick. It looks like something
> is going on in the code - not entirely sure just where yet (mine or
>
On Jan 13, 2012, at 7:29 AM, Nick Mathewson wrote:
> On Fri, Jan 13, 2012 at 7:47 AM, Ralph Castain wrote:
>> I've been digging further into this, and I believe I have much of it
>> resolved now. However, I have encountered a problem that appears to be
>> so
On Jan 13, 2012, at 8:29 AM, Nick Mathewson wrote:
> On Fri, Jan 13, 2012 at 10:13 AM, Ralph Castain wrote:
>
>>> What kind of illegal value are you seeing,
>>
>> 1326467251, 774650
>
> Okay, that looks like it's the actual current time! I wonder why th
On Jan 13, 2012, at 9:53 AM, Nick Mathewson wrote:
> On Fri, Jan 13, 2012 at 11:46 AM, Ralph Castain wrote:
>
>>> Adding some assertions in event_add_internal might track this down.
>>> Trivially, you could do
>>> if (tv && !tv_is_absolute) {
>&g
On Jan 13, 2012, at 12:40 PM, Nick Mathewson wrote:
>>if (ev == NULL) {
>>/* if no time-based events are active wait for I/O */
>>fprintf(stderr, "NO TIME-BASED EVENTS ACTIVE - tvp %d\n", (tv ==
>> NULL) ? -1 : (int)tv->tv_sec);
>>goto out;
>>
On Jan 13, 2012, at 12:40 PM, Nick Mathewson wrote:
>>if (ev == NULL) {
>>/* if no time-based events are active wait for I/O */
>>fprintf(stderr, "NO TIME-BASED EVENTS ACTIVE - tvp %d\n", (tv ==
>> NULL) ? -1 : (int)tv->tv_sec);
>>goto out;
>>
On Jan 13, 2012, at 12:56 PM, Nick Mathewson wrote:
> On Fri, Jan 13, 2012 at 2:52 PM, Ralph Castain wrote:
>>
>> Hah! I see what happened. I removed it because it was marked as an OMPI
>> change:
>>
>> - /OMPI CHANGE/
>&
Hi folks
I have a hopefully quick question. I've been chasing down memory corruption
issues, and think I'm coming to closure on the root cause.
If I setup an event by malloc'ing an event_t, am I allowed to free that memory
in the event handler when called by libevent? Or does libevent still nee
Never mind - RTFD plus some experimentation answered the question. Interesting
how it ran for years before finally exposing the problem.
On Feb 25, 2012, at 10:53 AM, Ralph Castain wrote:
> Hi folks
>
> I have a hopefully quick question. I've been chasing down memory corruption
Hi folks
I'm working with priorities in events using libevent 2.0.13. Since I'm not
using the most current release, I thought I'd ask about a behavior we are
seeing that might be a potential bug.
I have attached a simple reproducer of the problem. In short, suppose I have
setup 8 priorities fo
On Apr 30, 2012, at 2:30 PM, Nick Mathewson wrote:
> On Mon, Apr 30, 2012 at 3:53 PM, Ralph Castain wrote:
>> Hi folks
>>
>> I'm working with priorities in events using libevent 2.0.13. Since I'm not
>> using the most current release, I thought I'd a
On Apr 30, 2012, at 4:38 PM, Nick Mathewson wrote:
> On Mon, Apr 30, 2012 at 4:48 PM, Ralph Castain wrote:
>>
>> On Apr 30, 2012, at 2:30 PM, Nick Mathewson wrote:
>>
>>> On Mon, Apr 30, 2012 at 3:53 PM, Ralph Castain wrote:
>>>> Hi folks
>&g
On Apr 30, 2012, at 5:10 PM, Nick Mathewson wrote:
> On Mon, Apr 30, 2012 at 6:45 PM, Ralph Castain wrote:
> [...]
>> I'll take a look at your branch, but had some further thoughts in the
>> interim. Would a more optimal option be to add the following logic to
On Apr 30, 2012, at 7:49 PM, Nick Mathewson wrote:
> On Mon, Apr 30, 2012 at 7:17 PM, Ralph Castain wrote:
> [...]
>> The branch looks like it does the trick, and I like that it also does not
>> force the re-scan unless the newly activated event is a higher priority.
Hi folks
We have a case where we are running two parallel threads, each looping on their
own event base (we have the libevent thread support enabled). Even though the
two bases are running in separate threads, however, we see an impact on
response time - i.e., if we run only one thread, events
#x27;m not entirely sure how to confirm
> and/or measure that. Any thoughts would be appreciated, though I know it
> strays from libevent itself.
>
> Ralph
>
>
> On Nov 21, 2012, at 7:49 AM, Ralph Castain wrote:
>
>>
>> On Nov 21, 2012, at 7:26 AM, Nick Mathe
Hi folks
We're trying to support a system that has a really minimal OS on it - e.g., no
sockets or TCP/IP stack. Looking at libevent, and particularly at evutil.c, we
don't see a way to --disable-sockets.
Has anyone looked at considering such an option? Basically, what we need is to
strip libe
51 matches
Mail list logo
