> From: Libor Michalek [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 20, 2005 5:55 PM
>
> On Wed, Jul 20, 2005 at 05:17:09PM -0700, Fab Tillier wrote:
> > > From: Libor Michalek [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 20, 2005 5:02 PM
> > >
> > > My question is do we really wan
On Wed, Jul 20, 2005 at 05:17:09PM -0700, Fab Tillier wrote:
> > From: Libor Michalek [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 20, 2005 5:02 PM
> >
> > My question is do we really want this, since an application will likely
> > have yet another table containing the app specific connec
> From: Libor Michalek [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 20, 2005 5:02 PM
>
> My question is do we really want this, since an application will likely
> have yet another table containing the app specific connection structure.
> How that table is locked and managed will differ base
On Tue, Jul 12, 2005 at 10:20:33PM -0700, Fab Tillier wrote:
> > From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> > Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> > >
> > > I believe that this is purely a userspace issue. I can't see why
> > > using a mutex wouldn't work, but I believe that get_
On Tue, Jul 12, 2005 at 01:45:43PM -0700, Sean Hefty wrote:
> >> one way to handle this is to have destruction flush events first, then
> >> perform the actual destroy...
> >
> >Right, what I was trying to say in the other thread was: walk the event
> >list and kill events for the id that is destro
On Tue, Jul 12, 2005 at 11:53:06AM -0700, Sean Hefty wrote:
> This fell out of the uCM connection ID discussion...
>
> There's an issue reporting events to userspace clients for an object that
> a user may have destroyed. The problem exists with user verbs, but is
> much more likely to be seen by
>> > From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
>> > Sent: Tuesday, July 12, 2005 3:15 PM
>> >
>> > Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
>> > >
>> > > I believe that this is purely a userspace issue. I can't see why
>> > > using a mutex wouldn't work, but I believe that get_event() c
Quoting r. Fab Tillier <[EMAIL PROTECTED]>:
> Subject: RE: userspace event reporting
>
> > From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 12, 2005 3:15 PM
> >
> > Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> > >
> > > I believe that this is purely a userspace issue. I
> From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 12, 2005 3:15 PM
>
> Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> >
> > I believe that this is purely a userspace issue. I can't see why
> > using a mutex wouldn't work, but I believe that get_event() currently
> > blocks
Sean Hefty wrote:
Are we talking about multithreaded app?
Correct. The app is trying to get events while needing to destroy a cm_id (or
other object) at the same time.
So this is purely userspace issue - cant userspace just take some mutex
in get_event and destroy paths?
I be
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: userspace event reporting
>
> >Are we talking about multithreaded app?
>
> Correct. The app is trying to get events while needing to destroy a
> cm_id (or other object) at the same time.
>
> >So this is purely userspace issue - cant user
>Are we talking about multithreaded app?
Correct. The app is trying to get events while needing to destroy a cm_id (or
other object) at the same time.
>So this is purely userspace issue - cant userspace just take some mutex
>in get_event and destroy paths?
I believe that this is purely a usersp
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: userspace event reporting
>
> >> one way to handle this is to have destruction flush events first, then
> >> perform the actual destroy...
> >
> >Right, what I was trying to say in the other thread was: walk the event
> >list and kill event
>> one way to handle this is to have destruction flush events first, then
>> perform the actual destroy...
>
>Right, what I was trying to say in the other thread was: walk the event
>list and kill events for the id that is destroyed.
>
>Does this make more sense?
I think this is needed, just not s
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> one way to handle this is to have destruction flush events first, then
> perform the actual destroy...
Right, what I was trying to say in the other thread was: walk the event
list and kill events for the id that is destroyed.
Does this make more sense?
>For cq, there can only be one outstanding event of each kind at a time.
>So you can just keep a mask of events that happened, avoiding any mallocs.
>Is that not the same for cm?
For a listening cm_id, there could be multiple connection requests associated
with the listen in process at the same ti
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> >I think the proper solution is to record the event in the object itself.
> >For example, on cq event set bit "event received".
> >Then after object goes away events go away without flags, states and
> >ugliness.
>
> What we're suggesting is that the "e
>> This fell out of the uCM connection ID discussion...
>>
>> There's an issue reporting events to userspace clients for an object
>> that a user may have destroyed. The problem exists with user verbs,
>> but is much more likely to be seen by a userspace CM client. To avoid
>> reporting events fo
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: userspace event reporting
>
> This fell out of the uCM connection ID discussion...
>
> There's an issue reporting events to userspace clients for an object
> that a user may have destroyed. The problem exists with user verbs,
> but is much mo
19 matches
Mail list logo
