From rch at umail.ucsb.edu Thu Aug 2 20:01:35 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Aug 2 20:01:51 2007 Subject: [Tdg] OpenGL + linux? Message-ID: <46B29A8F.8030703@umail.ucsb.edu> What do you guys recommend for interfacing to OpenGL on linux? Glut? Will OSX be different? rama From alex at neisis.net Fri Aug 3 01:10:04 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 3 01:10:16 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <46B29A8F.8030703@umail.ucsb.edu> References: <46B29A8F.8030703@umail.ucsb.edu> Message-ID: <20070803081004.GW22042@silverninja.net> I figure glut is the easiest place to start if you're just concerned with rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. -Alex On 0, Rama Hoetzlein wrote: > What do you guys recommend for interfacing to OpenGL on linux? Glut? > Will OSX be different? > > rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From ljputnam at umail.ucsb.edu Fri Aug 3 11:46:25 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Aug 3 11:46:37 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803081004.GW22042@silverninja.net> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> Message-ID: <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> My question is, are we going to write native OS code or use 3rd party libs? I.e. what needs to be built from scratch? For Linux, we have to use an external windowing lib anyway, right? If so, maybe we can pick the most suitable one for all platforms so we don't have to completely start over... Lance Alex Norman wrote: > I figure glut is the easiest place to start if you're just concerned with > rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. > > -Alex > > On 0, Rama Hoetzlein wrote: >> What do you guys recommend for interfacing to OpenGL on linux? Glut? >> Will OSX be different? >> >> rama >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From alex at neisis.net Fri Aug 3 12:04:09 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 3 12:04:21 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> Message-ID: <20070803190409.GX22042@silverninja.net> By external windowing lib do you mean something on top of X like fltk or something? No, we don't need to use fltk, we can actually program for X if we want, I found an example for doing this and it doesn't look very difficult, I could code it up early this next week. I suggested glut as it was the "quick and dirty" way to get an opengl context, I figured rama was just wanting to try some stuff out. -Alex On 0, "Lance J. Putnam" wrote: > My question is, are we going to write native OS code or use 3rd party > libs? I.e. what needs to be built from scratch? For Linux, we have > to use an external windowing lib anyway, right? If so, maybe we can > pick the most suitable one for all platforms so we don't have to > completely start over... > > Lance > > Alex Norman wrote: > > >I figure glut is the easiest place to start if you're just concerned with > >rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. > > > >-Alex > > > >On 0, Rama Hoetzlein wrote: > >>What do you guys recommend for interfacing to OpenGL on linux? Glut? > >>Will OSX be different? > >> > >>rama > >>_______________________________________________ > >>Tdg mailing list > >>Tdg@mat.ucsb.edu > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From lists at grahamwakefield.net Fri Aug 3 12:08:50 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Aug 3 12:09:00 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> Message-ID: For OSX I would suggest using Cocoa rather than GLUT; GLUT is built on Cocoa/Carbon anyway. Me & Wes have code for both Carbon (C) and Cocoa (Obj-C) making windows and setting up GL contexts etc., but I would recommend building the underlying layer in Cocoa as the more OSX (i.e. future-scalable) way. It's pretty easy to separate this from the main C++ code base using a shared header file with some minimal function signatures defined (like, to handle message passing). Going native will also give us many useful extras for free (like file dialogs, OS services, etc.) Of course, this is more useful in the desktop rather than server scenario. On Aug 3, 2007, at 11:46 AM, Lance J. Putnam wrote: > My question is, are we going to write native OS code or use 3rd > party libs? I.e. what needs to be built from scratch? For Linux, > we have to use an external windowing lib anyway, right? If so, > maybe we can pick the most suitable one for all platforms so we > don't have to completely start over... > > Lance > > Alex Norman wrote: > >> I figure glut is the easiest place to start if you're just >> concerned with >> rendering OpenGL in an X or Aqua (osx's window manager [right?]) >> window. >> >> -Alex >> >> On 0, Rama Hoetzlein wrote: >>> What do you guys recommend for interfacing to OpenGL on linux? Glut? >>> Will OSX be different? >>> >>> rama >>> _______________________________________________ >>> Tdg mailing list >>> Tdg@mat.ucsb.edu >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> > > > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070803/a916e2ef/attachment-0001.html From wesley.hoke at gmail.com Fri Aug 3 12:36:15 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Aug 3 12:36:24 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> Message-ID: <1079b050708031236x4990708bu5aee4e433607384@mail.gmail.com> I was going to tackle Cocoa this weekend. I have some really nice example code I've been collecting from the 'net. wes On 8/3/07, Graham Wakefield wrote: > > For OSX I would suggest using Cocoa rather than GLUT; GLUT is built on > Cocoa/Carbon anyway. Me & Wes have code for both Carbon (C) and Cocoa > (Obj-C) making windows and setting up GL contexts etc., but I would > recommend building the underlying layer in Cocoa as the more OSX (i.e. > future-scalable) way. It's pretty easy to separate this from the main C++ > code base using a shared header file with some minimal function signatures > defined (like, to handle message passing). > > Going native will also give us many useful extras for free (like file > dialogs, OS services, etc.) Of course, this is more useful in the desktop > rather than server scenario. > > > On Aug 3, 2007, at 11:46 AM, Lance J. Putnam wrote: > > My question is, are we going to write native OS code or use 3rd party libs? > I.e. what needs to be built from scratch? For Linux, we have to use an > external windowing lib anyway, right? If so, maybe we can pick the most > suitable one for all platforms so we don't have to completely start over... > > Lance > > Alex Norman wrote: > > > I figure glut is the easiest place to start if you're just concerned with > rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. > > -Alex > > On 0, Rama Hoetzlein wrote: > What do you guys recommend for interfacing to OpenGL on linux? Glut? > Will OSX be different? > > rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > grrr waaa > www.grahamwakefield.net > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From ljputnam at umail.ucsb.edu Fri Aug 3 12:36:12 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Aug 3 12:36:25 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803190409.GX22042@silverninja.net> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> <20070803190409.GX22042@silverninja.net> Message-ID: <20070803123612.8paw9ww9kcssc4o4@webaccess.umail.ucsb.edu> Yes, FLTK is one. SDL is another option. I don't know what X gives you. Anything existing already that is cross-platform and can open a window, give you a GL context, and provide an interface to mouse, keyboard, and joystick will save us a lot of time. Lance Alex Norman wrote: > By external windowing lib do you mean something on top of X like fltk or > something? No, we don't need to use fltk, we can actually program > for X if we > want, I found an example for doing this and it doesn't look very difficult, I > could code it up early this next week. > I suggested glut as it was the "quick and dirty" way to get an > opengl context, I > figured rama was just wanting to try some stuff out. > > -Alex > > On 0, "Lance J. Putnam" wrote: >> My question is, are we going to write native OS code or use 3rd party >> libs? I.e. what needs to be built from scratch? For Linux, we have >> to use an external windowing lib anyway, right? If so, maybe we can >> pick the most suitable one for all platforms so we don't have to >> completely start over... >> >> Lance >> >> Alex Norman wrote: >> >> >I figure glut is the easiest place to start if you're just concerned with >> >rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. >> > >> >-Alex >> > >> >On 0, Rama Hoetzlein wrote: >> >>What do you guys recommend for interfacing to OpenGL on linux? Glut? >> >>Will OSX be different? >> >> >> >>rama >> >>_______________________________________________ >> >>Tdg mailing list >> >>Tdg@mat.ucsb.edu >> >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >_______________________________________________ >> >Tdg mailing list >> >Tdg@mat.ucsb.edu >> >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> > >> >> >> >> -- >> Lance Putnam >> Graduate Student >> Electronic Music and Sound Design >> Media Arts and Technology / UCSB >> ljputnam@umail.ucsb.edu >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From alex at neisis.net Fri Aug 3 12:39:32 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 3 12:39:45 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803123612.8paw9ww9kcssc4o4@webaccess.umail.ucsb.edu> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> <20070803190409.GX22042@silverninja.net> <20070803123612.8paw9ww9kcssc4o4@webaccess.umail.ucsb.edu> Message-ID: <20070803193931.GZ22042@silverninja.net> true, though it seems like others want to use the native windowing libraries.. maybe we should do this for X as well? -Alex On 0, "Lance J. Putnam" wrote: > Yes, FLTK is one. SDL is another option. I don't know what X gives > you. Anything existing already that is cross-platform and can open a > window, give you a GL context, and provide an interface to mouse, > keyboard, and joystick will save us a lot of time. > > Lance > > > Alex Norman wrote: > > >By external windowing lib do you mean something on top of X like fltk or > >something? No, we don't need to use fltk, we can actually program > >for X if we > >want, I found an example for doing this and it doesn't look very > >difficult, I > >could code it up early this next week. > >I suggested glut as it was the "quick and dirty" way to get an > >opengl context, I > >figured rama was just wanting to try some stuff out. > > > >-Alex > > > >On 0, "Lance J. Putnam" wrote: > >>My question is, are we going to write native OS code or use 3rd party > >>libs? I.e. what needs to be built from scratch? For Linux, we have > >>to use an external windowing lib anyway, right? If so, maybe we can > >>pick the most suitable one for all platforms so we don't have to > >>completely start over... > >> > >>Lance > >> > >>Alex Norman wrote: > >> > >>>I figure glut is the easiest place to start if you're just concerned with > >>>rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. > >>> > >>>-Alex > >>> > >>>On 0, Rama Hoetzlein wrote: > >>>>What do you guys recommend for interfacing to OpenGL on linux? Glut? > >>>>Will OSX be different? > >>>> > >>>>rama > >>>>_______________________________________________ > >>>>Tdg mailing list > >>>>Tdg@mat.ucsb.edu > >>>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >>>_______________________________________________ > >>>Tdg mailing list > >>>Tdg@mat.ucsb.edu > >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >>> > >> > >> > >> > >>-- > >>Lance Putnam > >>Graduate Student > >>Electronic Music and Sound Design > >>Media Arts and Technology / UCSB > >>ljputnam@umail.ucsb.edu > >> > >>_______________________________________________ > >>Tdg mailing list > >>Tdg@mat.ucsb.edu > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From ljputnam at umail.ucsb.edu Fri Aug 3 12:54:54 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Aug 3 12:55:06 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> Message-ID: <20070803125454.u1umxinmww4sowck@webaccess.umail.ucsb.edu> Yes, I think we should definitely follow the GLV windowing binding model. There are many useful extras in 3rd party libs that are also cross-platform. Lance Graham Wakefield wrote: > For OSX I would suggest using Cocoa rather than GLUT; GLUT is built on > Cocoa/Carbon anyway. Me & Wes have code for both Carbon (C) and Cocoa > (Obj-C) making windows and setting up GL contexts etc., but I would > recommend building the underlying layer in Cocoa as the more OSX (i.e. > future-scalable) way. It's pretty easy to separate this from the main > C++ code base using a shared header file with some minimal function > signatures defined (like, to handle message passing). > > Going native will also give us many useful extras for free (like file > dialogs, OS services, etc.) Of course, this is more useful in the > desktop rather than server scenario. > > On Aug 3, 2007, at 11:46 AM, Lance J. Putnam wrote: > >> My question is, are we going to write native OS code or use 3rd >> party libs? I.e. what needs to be built from scratch? For Linux, >> we have to use an external windowing lib anyway, right? If so, >> maybe we can pick the most suitable one for all platforms so we >> don't have to completely start over... >> >> Lance >> >> Alex Norman wrote: >> >>> I figure glut is the easiest place to start if you're just concerned with >>> rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. >>> >>> -Alex >>> >>> On 0, Rama Hoetzlein wrote: >>>> What do you guys recommend for interfacing to OpenGL on linux? Glut? >>>> Will OSX be different? >>>> >>>> rama >>>> _______________________________________________ >>>> Tdg mailing list >>>> Tdg@mat.ucsb.edu >>>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >>> _______________________________________________ >>> Tdg mailing list >>> Tdg@mat.ucsb.edu >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >>> >> >> >> >> -- >> Lance Putnam >> Graduate Student >> Electronic Music and Sound Design >> Media Arts and Technology / UCSB >> ljputnam@umail.ucsb.edu >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > grrr waaa > www.grahamwakefield.net -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From wesley.hoke at gmail.com Fri Aug 3 13:10:08 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Aug 3 13:10:17 2007 Subject: [Tdg] OpenGL + linux? In-Reply-To: <20070803193931.GZ22042@silverninja.net> References: <46B29A8F.8030703@umail.ucsb.edu> <20070803081004.GW22042@silverninja.net> <20070803114625.kn0ejvms000kcs0w@webaccess.umail.ucsb.edu> <20070803190409.GX22042@silverninja.net> <20070803123612.8paw9ww9kcssc4o4@webaccess.umail.ucsb.edu> <20070803193931.GZ22042@silverninja.net> Message-ID: <1079b050708031310t5293b27eqafac0fa6f696dbfe@mail.gmail.com> I think it would be good to do X. I wouldn't use SDL. It has alot of limitations from what I remember. More so than GLFW. wes On 8/3/07, Alex Norman wrote: > true, though it seems like others want to use the native windowing libraries.. > maybe we should do this for X as well? > > -Alex > > On 0, "Lance J. Putnam" wrote: > > Yes, FLTK is one. SDL is another option. I don't know what X gives > > you. Anything existing already that is cross-platform and can open a > > window, give you a GL context, and provide an interface to mouse, > > keyboard, and joystick will save us a lot of time. > > > > Lance > > > > > > Alex Norman wrote: > > > > >By external windowing lib do you mean something on top of X like fltk or > > >something? No, we don't need to use fltk, we can actually program > > >for X if we > > >want, I found an example for doing this and it doesn't look very > > >difficult, I > > >could code it up early this next week. > > >I suggested glut as it was the "quick and dirty" way to get an > > >opengl context, I > > >figured rama was just wanting to try some stuff out. > > > > > >-Alex > > > > > >On 0, "Lance J. Putnam" wrote: > > >>My question is, are we going to write native OS code or use 3rd party > > >>libs? I.e. what needs to be built from scratch? For Linux, we have > > >>to use an external windowing lib anyway, right? If so, maybe we can > > >>pick the most suitable one for all platforms so we don't have to > > >>completely start over... > > >> > > >>Lance > > >> > > >>Alex Norman wrote: > > >> > > >>>I figure glut is the easiest place to start if you're just concerned with > > >>>rendering OpenGL in an X or Aqua (osx's window manager [right?]) window. > > >>> > > >>>-Alex > > >>> > > >>>On 0, Rama Hoetzlein wrote: > > >>>>What do you guys recommend for interfacing to OpenGL on linux? Glut? > > >>>>Will OSX be different? > > >>>> > > >>>>rama > > >>>>_______________________________________________ > > >>>>Tdg mailing list > > >>>>Tdg@mat.ucsb.edu > > >>>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > >>>_______________________________________________ > > >>>Tdg mailing list > > >>>Tdg@mat.ucsb.edu > > >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > >>> > > >> > > >> > > >> > > >>-- > > >>Lance Putnam > > >>Graduate Student > > >>Electronic Music and Sound Design > > >>Media Arts and Technology / UCSB > > >>ljputnam@umail.ucsb.edu > > >> > > >>_______________________________________________ > > >>Tdg mailing list > > >>Tdg@mat.ucsb.edu > > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > >_______________________________________________ > > >Tdg mailing list > > >Tdg@mat.ucsb.edu > > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > > > > > > -- > > Lance Putnam > > Graduate Student > > Electronic Music and Sound Design > > Media Arts and Technology / UCSB > > ljputnam@umail.ucsb.edu > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From wesley.hoke at gmail.com Sat Aug 4 11:04:43 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 11:04:51 2007 Subject: [Tdg] overloading new puzzle Message-ID: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> So here's a tricky situation that I don't have a very good solution for right now. For doing the memory pool of events, it's really nice to overload the new/delete operators because the memory will be properly initialized by the object's constructor meaning member initialization and more importantly vtable initialization for virtual functions. The problem with the way new/delete work is that they are static functions with no sense of the calling context (i.e. which thread is active). What I want to be able to do is have at minimum a per-thread object factory containing a memory pool that objects' new/delete operators get the memory from. As far as I can tell, this requires setting some kind of static variable with the alloc/dealloc entry points from the object factory which could ptentially be interrupted by another thread so it has to be locked. I don't really want to lock an object's new/delete operators each time they are called but that might be what has to happen unless someone knows another way to initialize a block of memory to be a particular object. Of course the alternative to to redesign our event model so that creating new events don't have virtual functions and have some kind of static initialization function. Then the memory pool would just be a bunch of Event objects of a certain memory size which would get passed to the init function for setting up the data structure in memory. With no virtual functions, there would be no vtable and thus no need to run the object's constructor. This could pose a problem for memory deallocation though. Thoughts, opinions? wes From wesley.hoke at gmail.com Sat Aug 4 11:18:00 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 11:18:07 2007 Subject: [Tdg] Re: overloading new puzzle In-Reply-To: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> Message-ID: <1079b050708041118p269bf0e1o77da2fba51fc7359@mail.gmail.com> Another alternative is for each event class to have a static instance of itself that can be memcpy'd to new memory as an initializtion step so that the vtable will be properly constructed. As a side note, vtables a compiler specific so trying to access it directly and copy it into the properly location is not very portable. wes From lists at grahamwakefield.net Sat Aug 4 14:30:32 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sat Aug 4 14:30:43 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> Message-ID: <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> What I remember before is that we talked about getting the current threadID (there's a posix call for that) to determine the appropriate pool for the allocator (having different memory pools per thread rather than a global but thread-locked pool), but I don't think we ever tested it. A pool-per-thread seems viable for low numbers of persistent threads (and if the pools can be easily re-used for many types), but probably not scalable to large numbers of short-lived threads. Perhaps a combination of the two approaches? BTW, how does a delete know which pool it should return to - is there a private member pointer to the pool? What if delete is called from a different thread - that means you need a background garbage collector (i.e delete puts it in the recycle bin, then the pool's thread sweeps the bin periodically). Threading really sucks! Where are our atomic ops? The static function alternative is appealing in the low level, but not so nice for C++. Dealloc just means having a dealloc() static as well as an init(). Does the memcpy trick really work? I never imagined that, but it would be a neat trick. On Aug 4, 2007, at 11:04 AM, Wesley Smith wrote: > So here's a tricky situation that I don't have a very good solution > for right now. For doing the memory pool of events, it's really nice > to overload the new/delete operators because the memory will be > properly initialized by the object's constructor meaning member > initialization and more importantly vtable initialization for virtual > functions. > > The problem with the way new/delete work is that they are static > functions with no sense of the calling context (i.e. which thread is > active). What I want to be able to do is have at minimum a per-thread > object factory containing a memory pool that objects' new/delete > operators get the memory from. As far as I can tell, this requires > setting some kind of static variable with the alloc/dealloc entry > points from the object factory which could ptentially be interrupted > by another thread so it has to be locked. I don't really want to lock > an object's new/delete operators each time they are called but that > might be what has to happen unless someone knows another way to > initialize a block of memory to be a particular object. > > Of course the alternative to to redesign our event model so that > creating new events don't have virtual functions and have some kind of > static initialization function. Then the memory pool would just be a > bunch of Event objects of a certain memory size which would get passed > to the init function for setting up the data structure in memory. > With no virtual functions, there would be no vtable and thus no need > to run the object's constructor. This could pose a problem for memory > deallocation though. > > Thoughts, opinions? > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070804/a5db43d2/attachment.html From wesley.hoke at gmail.com Sat Aug 4 15:05:42 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 15:05:49 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> Message-ID: <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> So I have a functioning system right now. Here's how it works: For each event class, I'm creating a static instance of the class. For creating new events, there's an EventFactory that has an internal memory pool. It does a sizeof() on the event type to be created and allocates that much memory from the pool. It then hands off the uninitialized memory to the event class' static void create(Event *e); method. This does a memcpy (and yes it works) to initialize the memory. This event is then sent off to a central hub where it is distributed to the appropriate queue. when the queue is done with the event it class Event::recycle() which sends it back to the factory for recycling the memory back into its memory pool. This is all threadsafe to boot. I'm about to test is with sending OSC messages from one thread to a graphics thread and see how things pan out, but my test code (which is single threaded right now) shows things to be working well. There are some design issues about API we need to discuss like what defines a mint::Object or a mint::Event. Are they threadsafe? Have a memory pool? I think there is a very strong need for an EventFactory so how tightly is EventFactory coupled with Event? How is reference counting of Events done? How can one event be sent to multiple places? Is this even necessary? Once I get the networking test done, I'll try and summarize the design and potential issues for discussion in a more formal manner and put this stuff in SVN. wes From wesley.hoke at gmail.com Sat Aug 4 15:06:31 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 15:06:39 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> Message-ID: <1079b050708041506o2763cf54vff7a36915bc40500@mail.gmail.com> The problem with getCurrentThread() is that there could be multiple current threads on multiprocessor machines so I don't think this is viable. wes On 8/4/07, Wesley Smith wrote: > So I have a functioning system right now. Here's how it works: > > For each event class, I'm creating a static instance of the class. > For creating new events, there's an EventFactory that has an internal > memory pool. It does a sizeof() on the event type to be created and > allocates that much memory from the pool. It then hands off the > uninitialized memory to the event class' static void create(Event *e); > method. This does a memcpy (and yes it works) to initialize the > memory. > > This event is then sent off to a central hub where it is distributed > to the appropriate queue. when the queue is done with the event it > class Event::recycle() which sends it back to the factory for > recycling the memory back into its memory pool. > > This is all threadsafe to boot. I'm about to test is with sending OSC > messages from one thread to a graphics thread and see how things pan > out, but my test code (which is single threaded right now) shows > things to be working well. > > There are some design issues about API we need to discuss like what > defines a mint::Object or a mint::Event. Are they threadsafe? Have a > memory pool? I think there is a very strong need for an EventFactory > so how tightly is EventFactory coupled with Event? How is reference > counting of Events done? How can one event be sent to multiple > places? Is this even necessary? > > Once I get the networking test done, I'll try and summarize the design > and potential issues for discussion in a more formal manner and put > this stuff in SVN. > > wes > From lists at grahamwakefield.net Sat Aug 4 15:17:04 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sat Aug 4 15:17:15 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> Message-ID: Sounds great! How are you handling the case where Event::recycle() is called from a different thread to the one that constructed it? Are you locking or buffering on the recycle? How much of EventFactory is specific to Event? Would it be feasible to have Factory, and thus Factory, Factory etc.? G On Aug 4, 2007, at 3:05 PM, Wesley Smith wrote: > So I have a functioning system right now. Here's how it works: > > For each event class, I'm creating a static instance of the class. > For creating new events, there's an EventFactory that has an internal > memory pool. It does a sizeof() on the event type to be created and > allocates that much memory from the pool. It then hands off the > uninitialized memory to the event class' static void create(Event *e); > method. This does a memcpy (and yes it works) to initialize the > memory. > > This event is then sent off to a central hub where it is distributed > to the appropriate queue. when the queue is done with the event it > class Event::recycle() which sends it back to the factory for > recycling the memory back into its memory pool. > > This is all threadsafe to boot. I'm about to test is with sending OSC > messages from one thread to a graphics thread and see how things pan > out, but my test code (which is single threaded right now) shows > things to be working well. > > There are some design issues about API we need to discuss like what > defines a mint::Object or a mint::Event. Are they threadsafe? Have a > memory pool? I think there is a very strong need for an EventFactory > so how tightly is EventFactory coupled with Event? How is reference > counting of Events done? How can one event be sent to multiple > places? Is this even necessary? > > Once I get the networking test done, I'll try and summarize the design > and potential issues for discussion in a more formal manner and put > this stuff in SVN. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070804/e4e8cadd/attachment-0001.html From wesley.hoke at gmail.com Sat Aug 4 15:21:31 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 15:21:41 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> Message-ID: <1079b050708041521y648e9852t2d97d722a76011b9@mail.gmail.com> Events and EventFactory are coupled in that Event and a member variable EventFactory *owner which could be NULL if there isn't an owner. EventFactory can create any kind of event. Something I imagine will cause alot of debate is how I'm handling this right now. There's a user callback with a switch for all possible event types that can be created which is how the factory can create any event class based on an Event Type ID. The recycling doesn't have a lock except when the EventFactory::deleteEvents() method is called. This locks the recycle queues while their pointers are swapped and then cleans out the backside queue. wes On 8/4/07, Graham Wakefield wrote: > Sounds great! > > How are you handling the case where Event::recycle() is called from a > different thread to the one that constructed it? Are you locking or > buffering on the recycle? > > How much of EventFactory is specific to Event? Would it be feasible to have > Factory, and thus Factory, Factory etc.? > > G > > > On Aug 4, 2007, at 3:05 PM, Wesley Smith wrote: > > So I have a functioning system right now. Here's how it works: > > For each event class, I'm creating a static instance of the class. > For creating new events, there's an EventFactory that has an internal > memory pool. It does a sizeof() on the event type to be created and > allocates that much memory from the pool. It then hands off the > uninitialized memory to the event class' static void create(Event *e); > method. This does a memcpy (and yes it works) to initialize the > memory. > > This event is then sent off to a central hub where it is distributed > to the appropriate queue. when the queue is done with the event it > class Event::recycle() which sends it back to the factory for > recycling the memory back into its memory pool. > > This is all threadsafe to boot. I'm about to test is with sending OSC > messages from one thread to a graphics thread and see how things pan > out, but my test code (which is single threaded right now) shows > things to be working well. > > There are some design issues about API we need to discuss like what > defines a mint::Object or a mint::Event. Are they threadsafe? Have a > memory pool? I think there is a very strong need for an EventFactory > so how tightly is EventFactory coupled with Event? How is reference > counting of Events done? How can one event be sent to multiple > places? Is this even necessary? > > Once I get the networking test done, I'll try and summarize the design > and potential issues for discussion in a more formal manner and put > this stuff in SVN. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > > > grrr waaa > www.grahamwakefield.net > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From lists at grahamwakefield.net Sat Aug 4 15:52:49 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sat Aug 4 15:53:01 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <1079b050708041521y648e9852t2d97d722a76011b9@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> <1079b050708041521y648e9852t2d97d722a76011b9@mail.gmail.com> Message-ID: <49A98CCF-B65C-461E-B70C-72474A0B1ECC@grahamwakefield.net> On Aug 4, 2007, at 3:21 PM, Wesley Smith wrote: > Events and EventFactory are coupled in that Event and a member > variable EventFactory *owner which could be NULL if there isn't an > owner. OK. Templating this would get hairy, probably not much benefit. > EventFactory can create any kind of event. Something I imagine will > cause alot of debate is how I'm handling this right now. There's a > user callback with a switch for all possible event types that can be > created which is how the factory can create any event class based on > an Event Type ID. What was our final solution for event types & registration? I can't remember. Your factory create() method could be templated?: T * EventFactory::create() { ... } // inside MouseEvent's operator new: MouseEvent * e = EventFactory::create(); ... return e; I'm probably missing something important, right? > > The recycling doesn't have a lock except when the > EventFactory::deleteEvents() method is called. This locks the recycle > queues while their pointers are swapped and then cleans out the > backside queue. But when you insert into the backside queue, don't you need to lock there too? Is insertion into a queue threadsafe? (I think stl::queue for example is not threadsafe) > > wes > > On 8/4/07, Graham Wakefield wrote: >> Sounds great! >> >> How are you handling the case where Event::recycle() is called from a >> different thread to the one that constructed it? Are you locking or >> buffering on the recycle? >> >> How much of EventFactory is specific to Event? Would it be >> feasible to have >> Factory, and thus Factory, Factory etc.? >> >> G >> >> >> On Aug 4, 2007, at 3:05 PM, Wesley Smith wrote: >> >> So I have a functioning system right now. Here's how it works: >> >> For each event class, I'm creating a static instance of the class. >> For creating new events, there's an EventFactory that has an internal >> memory pool. It does a sizeof() on the event type to be created and >> allocates that much memory from the pool. It then hands off the >> uninitialized memory to the event class' static void create(Event >> *e); >> method. This does a memcpy (and yes it works) to initialize the >> memory. >> >> This event is then sent off to a central hub where it is distributed >> to the appropriate queue. when the queue is done with the event it >> class Event::recycle() which sends it back to the factory for >> recycling the memory back into its memory pool. >> >> This is all threadsafe to boot. I'm about to test is with sending >> OSC >> messages from one thread to a graphics thread and see how things pan >> out, but my test code (which is single threaded right now) shows >> things to be working well. >> >> There are some design issues about API we need to discuss like what >> defines a mint::Object or a mint::Event. Are they threadsafe? >> Have a >> memory pool? I think there is a very strong need for an EventFactory >> so how tightly is EventFactory coupled with Event? How is reference >> counting of Events done? How can one event be sent to multiple >> places? Is this even necessary? >> >> Once I get the networking test done, I'll try and summarize the >> design >> and potential issues for discussion in a more formal manner and put >> this stuff in SVN. >> >> wes >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> Graham Wakefield >> wakefield@mat.ucsb.edu >> www.mat.ucsb.edu/~wakefield >> >> >> >> >> >> >> grrr waaa >> www.grahamwakefield.net >> >> >> >> >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070804/bd7bfae6/attachment-0001.html From wesley.hoke at gmail.com Sat Aug 4 21:00:47 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Aug 4 21:00:55 2007 Subject: [Tdg] Competing framework? Message-ID: <1079b050708042100k613edf9dmdeadd58a8dfcc24a@mail.gmail.com> This is strikingly similar in language and scope to mint: http://instantreality.de/story/modules/ wes From alex at neisis.net Sun Aug 5 09:58:40 2007 From: alex at neisis.net (Alex Norman) Date: Sun Aug 5 09:58:55 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> Message-ID: <20070805165840.GE22042@silverninja.net> I was thinking something like this: class MemoryPoolable { private: memory_pool_id_t mMyPoolId; public: void* operator new (size_t size){ void * data = MemoryPool::getData(size); } void operator delete (void *p){ MemoryPool::freeData(p); } }; class MemoryPool { private: rw_mutex classLock; std::map MapThreadIDToPool; public: static void * getData(size_t size){ MemoryPool * poolToAllocFrom; rwlock_lock(classLock); //this looks up the curent thread id and gets the //associated memory pool [if there is one] poolToAllocFrom = MapThreadIDToPool.find(pthread_self()); rwlock_unlock(classLock); if(!poolToAllocFrom) return defaultPool.getData(size); else return poolToAllocFrom->getData(size); } freeData does just about the same thing except calling the pool's "free data" [which if you're in the pool's thread would push the data back onto its free list or what have you, otherwise it would push the data onto the pool's "to free when in context" queue. }; Here we have a Reader Writer lock (which pthreads provide), it allows as many readers as we want but only one writer. I think it is a good solution because we will be calling this WAY more often then we create threads [which will be rare I assume], so won't block us unless we're in the middle of creating a new memory pool/thread. The memory pool used is based on the calling thread's id, so you don't have to lock that pool, but if there is no pool associated with the thread, you'd use a default pool, which would probably lock [unless we can find some lock free way to do it]. delete then knows which pool to return to because either the pool's "id" is stored [or probably just a pointer to the pool]. If delete is called from a different thread then you'd have to push the data onto a queue associated with that thread's memory pool, and let it take care of it once it is in context. As Wes mentioned, another issue with Events is giving them a unique id. This either requires a lock free way to do myid = idCnt++; or to lock. -Alex On 0, Graham Wakefield wrote: > What I remember before is that we talked about getting the current > threadID (there's a posix call for that) to determine the appropriate > pool for the allocator (having different memory pools per thread > rather than a global but thread-locked pool), but I don't think we > ever tested it. > > A pool-per-thread seems viable for low numbers of persistent threads > (and if the pools can be easily re-used for many types), but probably > not scalable to large numbers of short-lived threads. Perhaps a > combination of the two approaches? > > BTW, how does a delete know which pool it should return to - is there > a private member pointer to the pool? What if delete is called from > a different thread - that means you need a background garbage > collector (i.e delete puts it in the recycle bin, then the pool's > thread sweeps the bin periodically). > > Threading really sucks! Where are our atomic ops? > > The static function alternative is appealing in the low level, but > not so nice for C++. Dealloc just means having a dealloc() static as > well as an init(). > > Does the memcpy trick really work? I never imagined that, but it > would be a neat trick. > > On Aug 4, 2007, at 11:04 AM, Wesley Smith wrote: > > >So here's a tricky situation that I don't have a very good solution > >for right now. For doing the memory pool of events, it's really nice > >to overload the new/delete operators because the memory will be > >properly initialized by the object's constructor meaning member > >initialization and more importantly vtable initialization for virtual > >functions. > > > >The problem with the way new/delete work is that they are static > >functions with no sense of the calling context (i.e. which thread is > >active). What I want to be able to do is have at minimum a per-thread > >object factory containing a memory pool that objects' new/delete > >operators get the memory from. As far as I can tell, this requires > >setting some kind of static variable with the alloc/dealloc entry > >points from the object factory which could ptentially be interrupted > >by another thread so it has to be locked. I don't really want to lock > >an object's new/delete operators each time they are called but that > >might be what has to happen unless someone knows another way to > >initialize a block of memory to be a particular object. > > > >Of course the alternative to to redesign our event model so that > >creating new events don't have virtual functions and have some kind of > >static initialization function. Then the memory pool would just be a > >bunch of Event objects of a certain memory size which would get passed > >to the init function for setting up the data structure in memory. > >With no virtual functions, there would be no vtable and thus no need > >to run the object's constructor. This could pose a problem for memory > >deallocation though. > > > >Thoughts, opinions? > > > >wes > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > grrr waaa > www.grahamwakefield.net > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sun Aug 5 10:00:14 2007 From: alex at neisis.net (Alex Norman) Date: Sun Aug 5 10:00:26 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <1079b050708041506o2763cf54vff7a36915bc40500@mail.gmail.com> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> <1079b050708041506o2763cf54vff7a36915bc40500@mail.gmail.com> Message-ID: <20070805170014.GF22042@silverninja.net> pthread_self() "The pthread_self() function returns the thread ID of the calling thread." I assume having multiple threads going isn't a problem because it returns the id of the calling thread, not the "current thread" -Alex On 0, Wesley Smith wrote: > The problem with getCurrentThread() is that there could be multiple > current threads on multiprocessor machines so I don't think this is > viable. > > wes > > On 8/4/07, Wesley Smith wrote: > > So I have a functioning system right now. Here's how it works: > > > > For each event class, I'm creating a static instance of the class. > > For creating new events, there's an EventFactory that has an internal > > memory pool. It does a sizeof() on the event type to be created and > > allocates that much memory from the pool. It then hands off the > > uninitialized memory to the event class' static void create(Event *e); > > method. This does a memcpy (and yes it works) to initialize the > > memory. > > > > This event is then sent off to a central hub where it is distributed > > to the appropriate queue. when the queue is done with the event it > > class Event::recycle() which sends it back to the factory for > > recycling the memory back into its memory pool. > > > > This is all threadsafe to boot. I'm about to test is with sending OSC > > messages from one thread to a graphics thread and see how things pan > > out, but my test code (which is single threaded right now) shows > > things to be working well. > > > > There are some design issues about API we need to discuss like what > > defines a mint::Object or a mint::Event. Are they threadsafe? Have a > > memory pool? I think there is a very strong need for an EventFactory > > so how tightly is EventFactory coupled with Event? How is reference > > counting of Events done? How can one event be sent to multiple > > places? Is this even necessary? > > > > Once I get the networking test done, I'll try and summarize the design > > and potential issues for discussion in a more formal manner and put > > this stuff in SVN. > > > > wes > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From lists at grahamwakefield.net Sun Aug 5 12:13:51 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sun Aug 5 12:13:59 2007 Subject: [Tdg] Competing framework? In-Reply-To: <1079b050708042100k613edf9dmdeadd58a8dfcc24a@mail.gmail.com> References: <1079b050708042100k613edf9dmdeadd58a8dfcc24a@mail.gmail.com> Message-ID: <9A83FF70-2C15-479D-9FF5-7005436E616F@grahamwakefield.net> Very interesting. More Allosphere than mint maybe? Looks like a merge of a few different projects. VRML is dead, long live X3D and all that. Competitor to bitmanagement et al? Can't find licensing info. As usual, sound appears to be an afterthought. Here's a few ideas for higher-level mint todo's (!): http:// www.instantreality.org/documentation/nodetypetree/ Why didn't we think of a Mint web-plugin before? That's such an obviously useful addition! On Aug 4, 2007, at 9:00 PM, Wesley Smith wrote: > This is strikingly similar in language and scope to mint: > http://instantreality.de/story/modules/ > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070805/c6053379/attachment.html From lists at grahamwakefield.net Sun Aug 5 13:16:02 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sun Aug 5 13:16:11 2007 Subject: [Tdg] overloading new puzzle In-Reply-To: <20070805170014.GF22042@silverninja.net> References: <1079b050708041104r464b535fmc158c56e761caf71@mail.gmail.com> <49CAA1A5-7859-4E86-9D21-5383170BBCD4@grahamwakefield.net> <1079b050708041505s26cb4885k7bd86ec3870f0c52@mail.gmail.com> <1079b050708041506o2763cf54vff7a36915bc40500@mail.gmail.com> <20070805170014.GF22042@silverninja.net> Message-ID: Here's some code (I'm putting it in the repo branches) to test pthread_self. I'm running 1024 threads with 1024 iterations calling printf() and testing against pthread_self on each one (thats a million tests and it is definitely spreading across both my cores when I look at the CPU monitor). I've run it a few times and it never fails. It's slow because of the printfs, but if I comment out the DOPRINT macro I run 10^9 tests and no fails, and it's fast enough I think. I think pthread_self() is a viable solution - but someone should say if there's something amiss with my test. Also I didn't try changing the pthread_attr_t values - maybe this will have an impact? #include #include #include #define NUMTHREADS (1024) #define DOPRINT #ifdef DOPRINT #define NUMITERATIONS (1024) #else #define NUMITERATIONS (1024 * 1024) #endif // thread function userdata struct TestData { pthread_t thread; // used to test identity with pthread_self() int id; // for printf }; // array of pthreads TestData tests[NUMTHREADS]; // global result flag bool failed = false; // thread callback: void * testfunc(void * arg) { TestData * test = (TestData *)arg; for (int i=0;ithread != pthread_self()) { printf("ERROR! pthread arg %p is not pthread_self() %p\n", test->thread, pthread_self()); failed = true; //exit(-1); } // pretty print to show thread interleaving and occaisional status #ifdef DOPRINT if (i % 16) { printf(",", i); } else { printf("%i[%i]: %p == %p\n", test->id, i, test->thread, pthread_self()); } #endif } } int main (int argc, char * const argv[]) { pthread_attr_t attr; pthread_attr_init(&attr); int err; // spawn some threads for (int i=0;i pthread_self() > "The pthread_self() function returns the thread ID of the calling > thread." > > I assume having multiple threads going isn't a problem because it > returns the > id of the calling thread, not the "current thread" > > -Alex > > On 0, Wesley Smith wrote: >> The problem with getCurrentThread() is that there could be multiple >> current threads on multiprocessor machines so I don't think this is >> viable. >> >> wes >> >> On 8/4/07, Wesley Smith wrote: >>> So I have a functioning system right now. Here's how it works: >>> >>> For each event class, I'm creating a static instance of the class. >>> For creating new events, there's an EventFactory that has an >>> internal >>> memory pool. It does a sizeof() on the event type to be created and >>> allocates that much memory from the pool. It then hands off the >>> uninitialized memory to the event class' static void create(Event >>> *e); >>> method. This does a memcpy (and yes it works) to initialize the >>> memory. >>> >>> This event is then sent off to a central hub where it is distributed >>> to the appropriate queue. when the queue is done with the event it >>> class Event::recycle() which sends it back to the factory for >>> recycling the memory back into its memory pool. >>> >>> This is all threadsafe to boot. I'm about to test is with >>> sending OSC >>> messages from one thread to a graphics thread and see how things pan >>> out, but my test code (which is single threaded right now) shows >>> things to be working well. >>> >>> There are some design issues about API we need to discuss like what >>> defines a mint::Object or a mint::Event. Are they threadsafe? >>> Have a >>> memory pool? I think there is a very strong need for an >>> EventFactory >>> so how tightly is EventFactory coupled with Event? How is reference >>> counting of Events done? How can one event be sent to multiple >>> places? Is this even necessary? >>> >>> Once I get the networking test done, I'll try and summarize the >>> design >>> and potential issues for discussion in a more formal manner and put >>> this stuff in SVN. >>> >>> wes >>> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg grrr waaa www.grahamwakefield.net From wesley.hoke at gmail.com Fri Aug 10 13:30:37 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Aug 10 13:30:45 2007 Subject: [Tdg] Docs/Meeting/Question Message-ID: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> So I'm working on doc'ing the event passing and memory pool work I've done. I should have it ready tommorrow. Do you all want to meet up on Monday to discuss it? I know there are going to be alot of things to figure out because this is just preliminary and will need quite a bit of work. Also, does anyone know if std::map[] access is threadsafe? Can I look at a map entry without having to lock it? wes From lists at grahamwakefield.net Fri Aug 10 13:39:11 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Aug 10 13:39:19 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> Message-ID: <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> sounds good. when & where? no idea about map, but stl in general is not threadsafe. btw did anyone else try out the pthread_self() code I sent, to see if it is safe on other architectures? G On Aug 10, 2007, at 1:30 PM, Wesley Smith wrote: > So I'm working on doc'ing the event passing and memory pool work I've > done. I should have it ready tommorrow. Do you all want to meet up > on Monday to discuss it? I know there are going to be alot of things > to figure out because this is just preliminary and will need quite a > bit of work. > > Also, does anyone know if std::map[] access is threadsafe? Can I look > at a map entry without having to lock it? > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070810/4d7906d1/attachment.html From alex at neisis.net Fri Aug 10 13:44:37 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 10 13:44:58 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> Message-ID: <20070810204437.GB12470@silverninja.net> I really doubt std::map is threadsafe, just put a rwlock around it. -Alex On 0, Wesley Smith wrote: > So I'm working on doc'ing the event passing and memory pool work I've > done. I should have it ready tommorrow. Do you all want to meet up > on Monday to discuss it? I know there are going to be alot of things > to figure out because this is just preliminary and will need quite a > bit of work. > > Also, does anyone know if std::map[] access is threadsafe? Can I look > at a map entry without having to lock it? > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Fri Aug 10 13:47:35 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Aug 10 13:47:42 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <20070810204437.GB12470@silverninja.net> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <20070810204437.GB12470@silverninja.net> Message-ID: <1079b050708101347o3fe3b0fref2b9fbef6634811@mail.gmail.com> I'm just talking abou read only access here not write. I'm 100% sure it's not write threadsafe, but read threadsafe I'm not sure. wes On 8/10/07, Alex Norman wrote: > I really doubt std::map is threadsafe, just put a rwlock around it. > -Alex > > On 0, Wesley Smith wrote: > > So I'm working on doc'ing the event passing and memory pool work I've > > done. I should have it ready tommorrow. Do you all want to meet up > > on Monday to discuss it? I know there are going to be alot of things > > to figure out because this is just preliminary and will need quite a > > bit of work. > > > > Also, does anyone know if std::map[] access is threadsafe? Can I look > > at a map entry without having to lock it? > > > > wes > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Fri Aug 10 13:50:13 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 10 13:50:28 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> Message-ID: <20070810205013.GC12470@silverninja.net> I just tried it, when I comment out the DOPRINT macro, it runs for a bit and then gives me: spawn 382 err 12 if I reduce the number of threads to 256 it completes for me: test complete: 256 threads of 1048576 iterations failed?: 0 -Alex On 0, Graham Wakefield wrote: > sounds good. when & where? > > no idea about map, but stl in general is not threadsafe. > > btw did anyone else try out the pthread_self() code I sent, to see if > it is safe on other architectures? > > G > > On Aug 10, 2007, at 1:30 PM, Wesley Smith wrote: > > >So I'm working on doc'ing the event passing and memory pool work I've > >done. I should have it ready tommorrow. Do you all want to meet up > >on Monday to discuss it? I know there are going to be alot of things > >to figure out because this is just preliminary and will need quite a > >bit of work. > > > >Also, does anyone know if std::map[] access is threadsafe? Can I look > >at a map entry without having to lock it? > > > >wes > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > grrr waaa > www.grahamwakefield.net > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Fri Aug 10 13:52:41 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 10 13:52:54 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <1079b050708101347o3fe3b0fref2b9fbef6634811@mail.gmail.com> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <20070810204437.GB12470@silverninja.net> <1079b050708101347o3fe3b0fref2b9fbef6634811@mail.gmail.com> Message-ID: <20070810205241.GD12470@silverninja.net> well, unless a read from a map modifies the contents of the map [which would be ridiculous], then it should be read thread safe right? either way, rwlocks allow you to have many readers, so if you're ever going to need to write, then a rwlock is probably going to be useful. -Alex On 0, Wesley Smith wrote: > I'm just talking abou read only access here not write. I'm 100% sure > it's not write threadsafe, but read threadsafe I'm not sure. > > wes > > On 8/10/07, Alex Norman wrote: > > I really doubt std::map is threadsafe, just put a rwlock around it. > > -Alex > > > > On 0, Wesley Smith wrote: > > > So I'm working on doc'ing the event passing and memory pool work I've > > > done. I should have it ready tommorrow. Do you all want to meet up > > > on Monday to discuss it? I know there are going to be alot of things > > > to figure out because this is just preliminary and will need quite a > > > bit of work. > > > > > > Also, does anyone know if std::map[] access is threadsafe? Can I look > > > at a map entry without having to lock it? > > > > > > wes > > > _______________________________________________ > > > Tdg mailing list > > > Tdg@mat.ucsb.edu > > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From lists at grahamwakefield.net Fri Aug 10 16:15:08 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Aug 10 16:15:19 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <20070810205013.GC12470@silverninja.net> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> <20070810205013.GC12470@silverninja.net> Message-ID: <09036E3F-B278-4916-B6A8-D66578B0E938@grahamwakefield.net> This is because on Linux the max no threads is pretty low. the spawn error is insufficient stack space or someting I think - this isn't the pthread_self() error. On Aug 10, 2007, at 1:50 PM, Alex Norman wrote: > I just tried it, when I comment out the DOPRINT macro, it runs for > a bit and > then gives me: > spawn 382 err 12 > > if I reduce the number of threads to 256 it completes for me: > test complete: 256 threads of 1048576 iterations > failed?: 0 > > -Alex > > On 0, Graham Wakefield wrote: >> sounds good. when & where? >> >> no idea about map, but stl in general is not threadsafe. >> >> btw did anyone else try out the pthread_self() code I sent, to see if >> it is safe on other architectures? >> >> G >> >> On Aug 10, 2007, at 1:30 PM, Wesley Smith wrote: >> >>> So I'm working on doc'ing the event passing and memory pool work >>> I've >>> done. I should have it ready tommorrow. Do you all want to meet up >>> on Monday to discuss it? I know there are going to be alot of >>> things >>> to figure out because this is just preliminary and will need quite a >>> bit of work. >>> >>> Also, does anyone know if std::map[] access is threadsafe? Can I >>> look >>> at a map entry without having to lock it? >>> >>> wes >>> _______________________________________________ >>> Tdg mailing list >>> Tdg@mat.ucsb.edu >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> Graham Wakefield >> wakefield@mat.ucsb.edu >> www.mat.ucsb.edu/~wakefield >> >> >> >> grrr waaa >> www.grahamwakefield.net >> >> >> >> > >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070810/a646341d/attachment-0001.html From lists at grahamwakefield.net Fri Aug 10 16:18:16 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Aug 10 16:18:24 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <20070810205013.GC12470@silverninja.net> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> <20070810205013.GC12470@silverninja.net> Message-ID: <98CC9C74-4382-4048-85B9-BADC6E881785@grahamwakefield.net> So, a) do you think it is fast, and b) do you think it is safe, and thus c) do you think pthread_self() is a good option for the per-thread memory pool implementation? Thansk! On Aug 10, 2007, at 1:50 PM, Alex Norman wrote: > I just tried it, when I comment out the DOPRINT macro, it runs for > a bit and > then gives me: > spawn 382 err 12 > > if I reduce the number of threads to 256 it completes for me: > test complete: 256 threads of 1048576 iterations > failed?: 0 > > -Alex > > On 0, Graham Wakefield wrote: >> sounds good. when & where? >> >> no idea about map, but stl in general is not threadsafe. >> >> btw did anyone else try out the pthread_self() code I sent, to see if >> it is safe on other architectures? >> >> G >> >> On Aug 10, 2007, at 1:30 PM, Wesley Smith wrote: >> >>> So I'm working on doc'ing the event passing and memory pool work >>> I've >>> done. I should have it ready tommorrow. Do you all want to meet up >>> on Monday to discuss it? I know there are going to be alot of >>> things >>> to figure out because this is just preliminary and will need quite a >>> bit of work. >>> >>> Also, does anyone know if std::map[] access is threadsafe? Can I >>> look >>> at a map entry without having to lock it? >>> >>> wes >>> _______________________________________________ >>> Tdg mailing list >>> Tdg@mat.ucsb.edu >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> Graham Wakefield >> wakefield@mat.ucsb.edu >> www.mat.ucsb.edu/~wakefield >> >> >> >> grrr waaa >> www.grahamwakefield.net >> >> >> >> > >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070810/e5219e81/attachment.html From alex at neisis.net Fri Aug 10 16:42:53 2007 From: alex at neisis.net (Alex Norman) Date: Fri Aug 10 16:43:07 2007 Subject: [Tdg] Docs/Meeting/Question In-Reply-To: <98CC9C74-4382-4048-85B9-BADC6E881785@grahamwakefield.net> References: <1079b050708101330g48c7753dxba5fb012c5a22ebb@mail.gmail.com> <67807B6F-4468-452E-B3E3-EE86EF67A68A@grahamwakefield.net> <20070810205013.GC12470@silverninja.net> <98CC9C74-4382-4048-85B9-BADC6E881785@grahamwakefield.net> Message-ID: <20070810234253.GF12470@silverninja.net> On 0, Graham Wakefield wrote: > So, > > a) do you think it is fast, and > b) do you think it is safe, and thus > c) do you think pthread_self() is a good option for the per-thread > memory pool implementation? a,b,c) yes I don't know exactly how to check its "speed", I did "gettimeofday" before and after the test and found the difference, I mostly got 1 or 2 usec, the worst I got was 5851 usec, but that could easily be due to a context switch. So, yeah, As I was saying earlier, having a 'lockless' pool per thread and a default locking pool as a fall back [in the case when it really doesn't matter and your thread doesn't need its own pool], I think is the way to go. This requires some sort of thread safe, multi writer single reader queue for deallocation though.. [when an event is deallocated in another thread] -Alex > > Thansk! > > On Aug 10, 2007, at 1:50 PM, Alex Norman wrote: > > >I just tried it, when I comment out the DOPRINT macro, it runs for > >a bit and > >then gives me: > >spawn 382 err 12 > > > >if I reduce the number of threads to 256 it completes for me: > >test complete: 256 threads of 1048576 iterations > >failed?: 0 > > > >-Alex > > > >On 0, Graham Wakefield wrote: > >>sounds good. when & where? > >> > >>no idea about map, but stl in general is not threadsafe. > >> > >>btw did anyone else try out the pthread_self() code I sent, to see if > >>it is safe on other architectures? > >> > >>G > >> > >>On Aug 10, 2007, at 1:30 PM, Wesley Smith wrote: > >> > >>>So I'm working on doc'ing the event passing and memory pool work > >>>I've > >>>done. I should have it ready tommorrow. Do you all want to meet up > >>>on Monday to discuss it? I know there are going to be alot of > >>>things > >>>to figure out because this is just preliminary and will need quite a > >>>bit of work. > >>> > >>>Also, does anyone know if std::map[] access is threadsafe? Can I > >>>look > >>>at a map entry without having to lock it? > >>> > >>>wes > >>>_______________________________________________ > >>>Tdg mailing list > >>>Tdg@mat.ucsb.edu > >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >> > >>Graham Wakefield > >>wakefield@mat.ucsb.edu > >>www.mat.ucsb.edu/~wakefield > >> > >> > >> > >>grrr waaa > >>www.grahamwakefield.net > >> > >> > >> > >> > > > >>_______________________________________________ > >>Tdg mailing list > >>Tdg@mat.ucsb.edu > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > grrr waaa > www.grahamwakefield.net > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sun Aug 12 11:31:34 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Aug 12 11:31:41 2007 Subject: [Tdg] TDG meets Message-ID: <1079b050708121131s1e641fcq7c3c5b38c0e00378@mail.gmail.com> So I was talking with A. Norman and he said he could meet on Monday at noon. Anyone else? @ the IGERT trailer. wes From lists at grahamwakefield.net Sun Aug 12 13:38:48 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sun Aug 12 13:38:56 2007 Subject: [Tdg] TDG meets In-Reply-To: <1079b050708121131s1e641fcq7c3c5b38c0e00378@mail.gmail.com> References: <1079b050708121131s1e641fcq7c3c5b38c0e00378@mail.gmail.com> Message-ID: <614F1854-6000-420E-9320-ED1BC9B14764@grahamwakefield.net> ok On Aug 12, 2007, at 11:31 AM, Wesley Smith wrote: > So I was talking with A. Norman and he said he could meet on Monday at > noon. Anyone else? @ the IGERT trailer. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070812/3baae463/attachment-0001.html From ljputnam at umail.ucsb.edu Sun Aug 12 23:56:44 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Sun Aug 12 23:57:03 2007 Subject: [Tdg] TDG meets In-Reply-To: <614F1854-6000-420E-9320-ED1BC9B14764@grahamwakefield.net> References: <1079b050708121131s1e641fcq7c3c5b38c0e00378@mail.gmail.com> <614F1854-6000-420E-9320-ED1BC9B14764@grahamwakefield.net> Message-ID: <20070812235644.ere62wxwggos08g0@webaccess.umail.ucsb.edu> fine here. Graham Wakefield wrote: > ok > > On Aug 12, 2007, at 11:31 AM, Wesley Smith wrote: > >> So I was talking with A. Norman and he said he could meet on Monday at >> noon. Anyone else? @ the IGERT trailer. >> >> wes >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > > grrr waaa > www.grahamwakefield.net -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From wesley.hoke at gmail.com Mon Aug 13 17:01:26 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Mon Aug 13 17:01:40 2007 Subject: [Tdg] Event system Message-ID: <1079b050708131701u2094015ftd77056786eedce75@mail.gmail.com> Ok graham, Take it away. I've got everything prepared for you to do the per-thread memory pool stuff. It's all checked in to the memory_pool branch. Let me know if you have any questions. wes From mail at grahamwakefield.net Wed Aug 15 09:05:39 2007 From: mail at grahamwakefield.net (Graham Wakefield) Date: Wed Aug 15 09:05:47 2007 Subject: [Tdg] cocoabrain Message-ID: <80AFA2C8-C0E8-4B67-AED1-CCF89CDE452C@grahamwakefield.net> Hey Wes, Could you svn up the cocoa project you had? I'd like to use it to test out remote brain stuff a bit. Thanks, G grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/39f56e82/attachment.html From xavier at create.ucsb.edu Sun Aug 5 23:09:55 2007 From: xavier at create.ucsb.edu (Xavier Amatriain) Date: Wed Aug 15 11:37:42 2007 Subject: [Allosphere-wg] Re: [Tdg] Competing framework? In-Reply-To: <9A83FF70-2C15-479D-9FF5-7005436E616F@grahamwakefield.net> References: <1079b050708042100k613edf9dmdeadd58a8dfcc24a@mail.gmail.com> <9A83FF70-2C15-479D-9FF5-7005436E616F@grahamwakefield.net> Message-ID: <46B6BB33.9050607@create.ucsb.edu> Remember that some time ago I was saying that uni-verse[1] was a really promising project for the Allosphere? Now I wonder how much in instantreality has been uplifted from uni-verse. Fraunhoffer IGD seems to be behind instantreality and they are also one of the partners in uni-verse. If you take a look at the tools in uni-verse, many do have a flavor that is very similar to the ones in instantreality... of course maybe all of them have been developed at Fraunhoffer but I'd bet the rest of the partners in Uni-verse are not very happy with this. [1] www.uni-verse.org Graham Wakefield wrote: > Very interesting. More Allosphere than mint maybe? > > Looks like a merge of a few different projects. VRML is dead, long > live X3D and all that. Competitor to bitmanagement et al? > > Can't find licensing info. > > As usual, sound appears to be an afterthought. > > Here's a few ideas for higher-level mint todo's > (!): http://www.instantreality.org/documentation/nodetypetree/ > > Why didn't we think of a Mint web-plugin before? That's such an > obviously useful addition! > > On Aug 4, 2007, at 9:00 PM, Wesley Smith wrote: > >> This is strikingly similar in language and scope to mint: >> http://instantreality.de/story/modules/ >> >> wes >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > grrr waaa > www.grahamwakefield.net > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Allosphere-wg mailing list > Allosphere-wg@create.ucsb.edu > http://www.create.ucsb.edu/mailman/listinfo/allosphere-wg > From wesley.hoke at gmail.com Sun Aug 12 01:33:50 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 11:37:43 2007 Subject: [Tdg] Mint Event System Message-ID: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> I've just checked in the latest MemoryPool and event system code into the branches/memory_pool folder. There's a simple demo using liblo for OSC messaging. Attached is a rough description of the system and its components. Much is up for discussion and redesign but at least we have something concrete to work with now. Some things in particular that should probably change: 1) using strings to register with the core and distribute events 2) deciding exactly what responsibilities an Event has in terms of memory management and reference counting and distribution Some things to discuss: 1) how free is event memory to travel outside of the basic event system 2) how are events allocated and what are their relationships to factories and memory pools Some things to keep an eye on: 1) mullti-threading and stl container insertion. I'm not sure I got everything locked up properly Any time on Monday is good for me to meet. When would be good for ya'll. wes -------------- next part -------------- A non-text attachment was scrubbed... Name: MintEventSystem.pdf Type: application/pdf Size: 489079 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070812/e40e421a/MintEventSystem-0001.pdf From jkm at create.ucsb.edu Wed Aug 15 11:42:25 2007 From: jkm at create.ucsb.edu (JoAnn Kuchera-Morin) Date: Wed Aug 15 11:42:38 2007 Subject: [Allosphere-wg] Re: [Tdg] Allosphere Brain Demo In-Reply-To: References: <006601c7cfcf$2c87b6a0$7bdd6f80@AcerLaptop> <26BFA192-2AED-468A-AE07-4755EC05ABAC@grahamwakefield.net> Message-ID: Hi Bo, We should find out if Larry Zins is taking care of lab repairs... On Jul 26, 2007, at 6:33 PM, Bo Bell wrote: > For what it's worth: the DVD burner on the G5 in 2809 is not working > properly. I don't think that anyone keeps up with such things these > days, but I wanted to put it out there. I for one would welcome the > switch, so as to have a more powerful and reliable machine in the lab. > > -B > > On Jul 26, 2007, at 3:09 PM, Graham Wakefield wrote: > >> Right-o >> >> Just let me know what day you want to do it (any day except Tue). >> >> G >> >> On Jul 26, 2007, at 2:51 PM, Brent Oster wrote: >> >>> >>> You can still use the Mac as a master and the PC?s as render nodes. >>> >>> ? >>> >>> We?d like to have the Mac that is currently in 2809 running as the >>> master so we can use the other one (currently in Allosphere) as a >>> modeling and data processing workstation. >>> >>> ? >>> >>> >>> From: tdg-bounces@mat.ucsb.edu [mailto:tdg-bounces@mat.ucsb.edu] On >>> Behalf Of Graham Wakefield >>> Sent: Thursday, July 26, 2007 1:09 PM >>> To: tdg@mat.ucsb.edu >>> Subject: Re: [Tdg] Allosphere Brain Demo >>> >>> ? >>> >>> Hi, >>> >>> ? >>> >>> I'm pretty out of date with what is happening in the sphere! >>> >>> ? >>> >>> Before, we had the MacPro running as the 'master' node, handling >>> user input, the main navigation and interaction code etc, and also >>> responsible for audio, and the two Windows boxes as 'render' nodes >>> doing the GL. The 'master' and 'render' nodes interacted via UDP >>> multicast. The separation of duties alleviated CPU resources quite >>> nicely, and allowed for scalability up to many more >>> renderers/projectors. >>> >>> ? >>> >>> Are we moving to a single computer setup, or will there still be a >>> separation of controller / audio / graphics? I'm not sure a single >>> machine is going to handle both the audio and the graphics smoothly. >>> >>> ? >>> >>> BTW, until the brain project is ported to a C++ (Mint?) base, it's >>> XP or OSX only because of Max/MSP/Jitter. >>> >>> ? >>> >>> ? >>> >>> On Jul 26, 2007, at 12:39 PM, Brent Oster wrote: >>> >>> >>> >>> We are configuring an HP XW9400 with 32-bit windows / 32-bit Linux >>> dual boot. It will have an nVidia Quaddro FX5600 board in it. >>> >>> ? >>> >>> >>> From: tdg-bounces@mat.ucsb.edu [mailto:tdg-bounces@mat.ucsb.edu] On >>> Behalf Of Graham Wakefield >>> Sent: Thursday, July 26, 2007 11:47 AM >>> To: tdg@mat.ucsb.edu >>> Cc: allosphere-wg@create.ucsb.edu >>> Subject: Re: [Tdg] Allosphere Brain Demo >>> >>> ? >>> >>> I should be able to do this, I think! Certainly I have the new >>> content ready to go anyway. >>> >>> ? >>> >>> What are the new workstations? >>> >>> ? >>> >>> On Jul 26, 2007, at 11:40 AM, Brent Oster wrote: >>> >>> >>> >>> >>> >>> I was wondering if somebody would be willing to port the Allosphere >>> brain demo over to another workstation, and add the new content for >>> us? >>> >>> ? >>> >>> We?re trying to consolidate all of our demos onto a single >>> workstation so that we don?t have to keep swapping cables and moving >>> projectors every time someone wants to demo what we have on the >>> Allosphere. >>> >>> _______________________________________________ >>> >>> Tdg mailing list >>> >>> Tdg@mat.ucsb.edu >>> >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >>> >>> ? >>> >>> >>> Graham Wakefield >>> >>> wakefield@mat.ucsb.edu >>> >>> www.mat.ucsb.edu/~wakefield >>> >>> ? >>> >>> >>> >>> >>> ? >>> >>> >>> grrr waaa >>> >>> www.grahamwakefield.net >>> >>> ? >>> >>> ? >>> >>> >>> >>> >>> ? >>> >>> _______________________________________________ >>> >>> Tdg mailing list >>> >>> Tdg@mat.ucsb.edu >>> >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >>> >>> ? >>> >>> >>> Graham Wakefield >>> >>> wakefield@mat.ucsb.edu >>> >>> www.mat.ucsb.edu/~wakefield >>> >>> ? >>> >>> >>> >>> ? >>> >>> >>> grrr waaa >>> >>> www.grahamwakefield.net >>> >>> ? >>> >>> ? >>> >>> >>> >>> ? >>> _______________________________________________ >>> Tdg mailing list >>> Tdg@mat.ucsb.edu >>> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> grrr waaa >> www.grahamwakefield.net >> >> >> >> >> >> _______________________________________________ >> Allosphere-wg mailing list >> Allosphere-wg@create.ucsb.edu >> http://www.create.ucsb.edu/mailman/listinfo/allosphere-wg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > -- Dr. JoAnn Kuchera-Morin Director, Allosphere Research Laboratory Media Arts and Technology Initiatives, MAT-CNSI Media Arts and Technology, California Nanosystems Institute Professor, Graduate Program in Media Arts and Technology Professor of Composition, Department of Music Director, Center for Research in Electronic Art Technology University of California, Santa Barbara http://www.mat.ucsb.edu/allosphere http://www.mat.ucsb.edu http://www.create.ucsb.edu ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 11119 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/edce829a/attachment.bin From wesley.hoke at gmail.com Wed Aug 15 12:37:38 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 12:37:45 2007 Subject: [Tdg] cocoabrain In-Reply-To: <80AFA2C8-C0E8-4B67-AED1-CCF89CDE452C@grahamwakefield.net> References: <80AFA2C8-C0E8-4B67-AED1-CCF89CDE452C@grahamwakefield.net> Message-ID: <1079b050708151237s507b4542h927d452b7c78926f@mail.gmail.com> It's in there now. wes On 8/15/07, Graham Wakefield wrote: > Hey Wes, > > Could you svn up the cocoa project you had? I'd like to use it to test out > remote brain stuff a bit. > > Thanks, > > G > > > grrr waaa > www.grahamwakefield.net > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From wesley.hoke at gmail.com Wed Aug 15 13:22:01 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 13:22:09 2007 Subject: [Tdg] OSC Message-ID: <1079b050708151322s13bdf0a1o8dc04ffdf03f56ba@mail.gmail.com> Hey Alex, Could you drop your OSC stuff you showed us on Monday into the suppository? I'd like to check out your design in more detail and see how it could possibly be applied to generic event arguments for the generic event constructor. thanks, wes From lists at grahamwakefield.net Wed Aug 15 13:25:20 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Wed Aug 15 13:25:37 2007 Subject: [Tdg] Mint Event System In-Reply-To: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> Message-ID: <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> Ah- I just checked in some code to the pthread_test branch, adding single/ multi threaded wrappers to your MemoryPool. This differs quite a bit from your doc, sorry. I wanted to extend memory management beyond the event class to be more generic. Rather than making a Factory per class, I made a generic class MemoryManaged that any class can inherit from, which does the appropriate overloading of new, delete etc. All classes in a thread share the same pool (yes, they can be different sizes, but events themselves would be anyway, right?) There's a memory pool per thread stored in a static map in MemoryManaged, and you can tell it what threads to manage (by the pthread_t or just 'current thread') using static methods. It does require manually triggering emptyTrash() however to reclaim memory. I think this is pretty much what EventFactory was doing, except without the map of constructors. So for a usage example: the root Event class should inherit from MemoryManaged the various threads that will use a lot of events should call MemoryManaged::manageThread() on themselves and they should periodically call MemoryManaged::emptyTrash() to clear their recycle buffers Otherwise, using new and delete continues as normal. So - the issues. Deleting a managed object from a different thread involves a brief mutex lock to stick it on the recycle buffer (but emptying trash using trylock and just does a quick pointer swap). Any managed item allocated in an unmanaged thread will use a shared, mutex-locked memory pool for allocation and deletion (we still hope that a mutex and map index are faster than malloc/free, right?) - So, I guess what I've done will be useful, but maybe to make it work with Events/Factories/Hub needs a bit more thought. Are the EventFactories necessarily single-threaded? When I create an OSC event to send (rather than receive), it might happen from any thread. Once it has been used, it can be recycled, which will probably happen somewhere else. Is multithreaded fan in using a mutex, and how would it be scheduled? On Aug 12, 2007, at 1:33 AM, Wesley Smith wrote: > I've just checked in the latest MemoryPool and event system code into > the branches/memory_pool folder. There's a simple demo using liblo > for OSC messaging. Attached is a rough description of the system and > its components. Much is up for discussion and redesign but at least > we have something concrete to work with now. > > Some things in particular that should probably change: > > 1) using strings to register with the core and distribute events > 2) deciding exactly what responsibilities an Event has in terms of > memory management and reference counting and distribution > > > Some things to discuss: > > 1) how free is event memory to travel outside of the basic event > system > 2) how are events allocated and what are their relationships to > factories and memory pools > > > Some things to keep an eye on: > > 1) mullti-threading and stl container insertion. I'm not sure I got > everything locked up properly > > > > Any time on Monday is good for me to meet. When would be good for > ya'll. > > wes > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/65eb774c/attachment-0001.html From wesley.hoke at gmail.com Wed Aug 15 13:47:47 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 13:47:55 2007 Subject: [Tdg] Mint Event System In-Reply-To: <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> Message-ID: <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> For recycling, there could be a list of queues for each thread in MemoryManaged that would be pointer swapped and trylocked on recycling but when something is deleted can be dropped in the appropriate queue. Would this help? wes On 8/15/07, Graham Wakefield wrote: > > Ah- > > I just checked in some code to the pthread_test branch, adding single/multi > threaded wrappers to your MemoryPool. This differs quite a bit from your > doc, sorry. I wanted to extend memory management beyond the event class to > be more generic. > > Rather than making a Factory per class, I made a generic class MemoryManaged > that any class can inherit from, which does the appropriate overloading of > new, delete etc. All classes in a thread share the same pool (yes, they can > be different sizes, but events themselves would be anyway, right?) There's > a memory pool per thread stored in a static map in MemoryManaged, and you > can tell it what threads to manage (by the pthread_t or just 'current > thread') using static methods. It does require manually triggering > emptyTrash() however to reclaim memory. I think this is pretty much what > EventFactory was doing, except without the map of constructors. > > So for a usage example: > the root Event class should inherit from MemoryManaged > the various threads that will use a lot of events should call > MemoryManaged::manageThread() on themselves > and they should periodically call MemoryManaged::emptyTrash() to clear > their recycle buffers > > Otherwise, using new and delete continues as normal. > > So - the issues. Deleting a managed object from a different thread involves > a brief mutex lock to stick it on the recycle buffer (but emptying trash > using trylock and just does a quick pointer swap). > Any managed item allocated in an unmanaged thread will use a shared, > mutex-locked memory pool for allocation and deletion (we still hope that a > mutex and map index are faster than malloc/free, right?) > > - > > So, I guess what I've done will be useful, but maybe to make it work with > Events/Factories/Hub needs a bit more thought. > > Are the EventFactories necessarily single-threaded? When I create an OSC > event to send (rather than receive), it might happen from any thread. Once > it has been used, it can be recycled, which will probably happen somewhere > else. > > Is multithreaded fan in using a mutex, and how would it be scheduled? > > > > On Aug 12, 2007, at 1:33 AM, Wesley Smith wrote: > > I've just checked in the latest MemoryPool and event system code into > the branches/memory_pool folder. There's a simple demo using liblo > for OSC messaging. Attached is a rough description of the system and > its components. Much is up for discussion and redesign but at least > we have something concrete to work with now. > > Some things in particular that should probably change: > > 1) using strings to register with the core and distribute events > 2) deciding exactly what responsibilities an Event has in terms of > memory management and reference counting and distribution > > > Some things to discuss: > > 1) how free is event memory to travel outside of the basic event system > 2) how are events allocated and what are their relationships to > factories and memory pools > > > Some things to keep an eye on: > > 1) mullti-threading and stl container insertion. I'm not sure I got > everything locked up properly > > > > Any time on Monday is good for me to meet. When would be good for ya'll. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > grrr waaa > www.grahamwakefield.net > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From lists at grahamwakefield.net Wed Aug 15 14:54:14 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Wed Aug 15 14:54:24 2007 Subject: [Tdg] Mint Event System In-Reply-To: <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> Message-ID: <2E0913A1-4943-4DF4-99E8-C3263888A2C1@grahamwakefield.net> Thing is, the list of queues would not be static, i.e. when a new thread is created (or removed), and thus would itself need locking, plus every thread has a queue for every other. Does this scenario work?: class ManagedThread { threadId // the thread it manages MemoryPool // the memory pool for this thread vector Deleted // objects 'deleted' in this thread vector Recycler // objects ready for memory recycling in this thread's Pool ... } class Object { ManagedThread * mOwner; // ManagedThread in which it was created, or NULL ... } A day in the life of an Object: ManagedThread 1 creates Object a: finds that ManagedThread1 is managed and allocates from MemoryPool 1 (no locking) ManagedThread 2 tries to delete Object a: finds that ManagedThread2 is managed and so places it on Deleted 2 (no locking) emptyTrash happens in ManagedThread 2: checks Deleted: finds Object a, belongs to ManagedThread 1: attempts to put in Recycler 1 (trylocked with recycler-mutex) checks Recycler: nothing emptyTrash happens in ManagedThread 1: checks Deleted: nothing checks Recycler: finds Object a pops from Recycler and reclaims to MemoryPool 1 (trylocked with recycler-mutex) This method never calls mutex_lock, and only requires that emptyTrash is called periodically in every managed thread. This could be automated in the delete() call itself, by for example triggering emptyTrash every N times delete is called, and progressing M steps (or percent) through the queue and recycler each time to minimize burstiness. Some other speedups - probably stack or whatever is better than vector. Delete could attempt (trylock) to place in the other thread's Recycler immediately, and store in local Deleted only if the trylock fails. Not sure what would happen if you deleted from an unmanaged thread. Probably needs to go into a default Deleted queue that IS locked, and somehow trigger an emptyTrash call on the default Deleted queue periodically from the main loop. Pennies for thoughts? Are you in CNSI? On Aug 15, 2007, at 1:47 PM, Wesley Smith wrote: > For recycling, there could be a list of queues for each thread in > MemoryManaged that would be pointer swapped and trylocked on recycling > but when something is deleted can be dropped in the appropriate queue. > Would this help? > > wes > > On 8/15/07, Graham Wakefield wrote: >> >> Ah- >> >> I just checked in some code to the pthread_test branch, adding >> single/multi >> threaded wrappers to your MemoryPool. This differs quite a bit >> from your >> doc, sorry. I wanted to extend memory management beyond the event >> class to >> be more generic. >> >> Rather than making a Factory per class, I made a generic class >> MemoryManaged >> that any class can inherit from, which does the appropriate >> overloading of >> new, delete etc. All classes in a thread share the same pool >> (yes, they can >> be different sizes, but events themselves would be anyway, >> right?) There's >> a memory pool per thread stored in a static map in MemoryManaged, >> and you >> can tell it what threads to manage (by the pthread_t or just 'current >> thread') using static methods. It does require manually triggering >> emptyTrash() however to reclaim memory. I think this is pretty >> much what >> EventFactory was doing, except without the map of constructors. >> >> So for a usage example: >> the root Event class should inherit from MemoryManaged >> the various threads that will use a lot of events should call >> MemoryManaged::manageThread() on themselves >> and they should periodically call MemoryManaged::emptyTrash() to >> clear >> their recycle buffers >> >> Otherwise, using new and delete continues as normal. >> >> So - the issues. Deleting a managed object from a different >> thread involves >> a brief mutex lock to stick it on the recycle buffer (but emptying >> trash >> using trylock and just does a quick pointer swap). >> Any managed item allocated in an unmanaged thread will use a shared, >> mutex-locked memory pool for allocation and deletion (we still >> hope that a >> mutex and map index are faster than malloc/free, right?) >> >> - >> >> So, I guess what I've done will be useful, but maybe to make it >> work with >> Events/Factories/Hub needs a bit more thought. >> >> Are the EventFactories necessarily single-threaded? When I create >> an OSC >> event to send (rather than receive), it might happen from any >> thread. Once >> it has been used, it can be recycled, which will probably happen >> somewhere >> else. >> >> Is multithreaded fan in using a mutex, and how would it be scheduled? >> >> >> >> On Aug 12, 2007, at 1:33 AM, Wesley Smith wrote: >> >> I've just checked in the latest MemoryPool and event system code into >> the branches/memory_pool folder. There's a simple demo using liblo >> for OSC messaging. Attached is a rough description of the system and >> its components. Much is up for discussion and redesign but at least >> we have something concrete to work with now. >> >> Some things in particular that should probably change: >> >> 1) using strings to register with the core and distribute events >> 2) deciding exactly what responsibilities an Event has in terms of >> memory management and reference counting and distribution >> >> >> Some things to discuss: >> >> 1) how free is event memory to travel outside of the basic event >> system >> 2) how are events allocated and what are their relationships to >> factories and memory pools >> >> >> Some things to keep an eye on: >> >> 1) mullti-threading and stl container insertion. I'm not sure I got >> everything locked up properly >> >> >> >> Any time on Monday is good for me to meet. When would be good for >> ya'll. >> >> wes >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> Graham Wakefield >> wakefield@mat.ucsb.edu >> www.mat.ucsb.edu/~wakefield >> >> >> >> >> grrr waaa >> www.grahamwakefield.net >> >> >> >> >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg Graham Wakefield wakefield@mat.ucsb.edu www.mat.ucsb.edu/~wakefield grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/ef67e944/attachment-0001.html From wesley.hoke at gmail.com Wed Aug 15 15:02:52 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 15:03:01 2007 Subject: [Tdg] Mint Event System In-Reply-To: <2E0913A1-4943-4DF4-99E8-C3263888A2C1@grahamwakefield.net> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> <2E0913A1-4943-4DF4-99E8-C3263888A2C1@grahamwakefield.net> Message-ID: <1079b050708151502l3772d44cq202ac886a9f49b33@mail.gmail.com> I'm not in CNSI today but I could be tommorrow to discuss this and figure out the brain stuff. The day in a life description sounds good. Here was my technique for recycling: On Recycle: **objects to be recycled are held in a std::queue - for each object in the queue - get its pointer - pop it from queue - try to recycle it - on failure, push it back on the queue The queue is fast to pop and push and if things don't get recycled, then no biggie, it will attempt to recycle it the next time. Older memory blocks will also accumulate at the front of the queue (not that this really matters, but is kind of a nice consequence). wes On 8/15/07, Graham Wakefield wrote: > > Thing is, the list of queues would not be static, i.e. when a new thread is > created (or removed), and thus would itself need locking, plus every thread > has a queue for every other. > > Does this scenario work?: > > class ManagedThread { > threadId // the thread it manages > MemoryPool // the memory pool for this thread > vector Deleted // objects 'deleted' in this thread > vector Recycler // objects ready for memory recycling in this > thread's Pool > ... > } > > class Object { > ManagedThread * mOwner; // ManagedThread in which it was created, or NULL > ... > } > > A day in the life of an Object: > > ManagedThread 1 creates Object a: > finds that ManagedThread1 is managed and allocates from MemoryPool 1 (no > locking) > ManagedThread 2 tries to delete Object a: > finds that ManagedThread2 is managed and so places it on Deleted 2 (no > locking) > > emptyTrash happens in ManagedThread 2: > checks Deleted: finds Object a, belongs to ManagedThread 1: > attempts to put in Recycler 1 (trylocked with recycler-mutex) > checks Recycler: nothing > > emptyTrash happens in ManagedThread 1: > checks Deleted: nothing > checks Recycler: finds Object a > pops from Recycler and reclaims to MemoryPool 1 (trylocked with > recycler-mutex) > > This method never calls mutex_lock, and only requires that emptyTrash is > called periodically in every managed thread. This could be automated in the > delete() call itself, by for example triggering emptyTrash every N times > delete is called, and progressing M steps (or percent) through the queue and > recycler each time to minimize burstiness. > > Some other speedups - probably stack or whatever is better than vector. > Delete could attempt (trylock) to place in the other thread's Recycler > immediately, and store in local Deleted only if the trylock fails. > > Not sure what would happen if you deleted from an unmanaged thread. > Probably needs to go into a default Deleted queue that IS locked, and > somehow trigger an emptyTrash call on the default Deleted queue periodically > from the main loop. > > Pennies for thoughts? > > Are you in CNSI? > > > On Aug 15, 2007, at 1:47 PM, Wesley Smith wrote: > > For recycling, there could be a list of queues for each thread in > MemoryManaged that would be pointer swapped and trylocked on recycling > but when something is deleted can be dropped in the appropriate queue. > Would this help? > > wes > > On 8/15/07, Graham Wakefield wrote: > > Ah- > > I just checked in some code to the pthread_test branch, adding single/multi > threaded wrappers to your MemoryPool. This differs quite a bit from your > doc, sorry. I wanted to extend memory management beyond the event class to > be more generic. > > Rather than making a Factory per class, I made a generic class MemoryManaged > that any class can inherit from, which does the appropriate overloading of > new, delete etc. All classes in a thread share the same pool (yes, they can > be different sizes, but events themselves would be anyway, right?) There's > a memory pool per thread stored in a static map in MemoryManaged, and you > can tell it what threads to manage (by the pthread_t or just 'current > thread') using static methods. It does require manually triggering > emptyTrash() however to reclaim memory. I think this is pretty much what > EventFactory was doing, except without the map of constructors. > > So for a usage example: > the root Event class should inherit from MemoryManaged > the various threads that will use a lot of events should call > MemoryManaged::manageThread() on themselves > and they should periodically call MemoryManaged::emptyTrash() to clear > their recycle buffers > > Otherwise, using new and delete continues as normal. > > So - the issues. Deleting a managed object from a different thread involves > a brief mutex lock to stick it on the recycle buffer (but emptying trash > using trylock and just does a quick pointer swap). > Any managed item allocated in an unmanaged thread will use a shared, > mutex-locked memory pool for allocation and deletion (we still hope that a > mutex and map index are faster than malloc/free, right?) > > - > > So, I guess what I've done will be useful, but maybe to make it work with > Events/Factories/Hub needs a bit more thought. > > Are the EventFactories necessarily single-threaded? When I create an OSC > event to send (rather than receive), it might happen from any thread. Once > it has been used, it can be recycled, which will probably happen somewhere > else. > > Is multithreaded fan in using a mutex, and how would it be scheduled? > > > > On Aug 12, 2007, at 1:33 AM, Wesley Smith wrote: > > I've just checked in the latest MemoryPool and event system code into > the branches/memory_pool folder. There's a simple demo using liblo > for OSC messaging. Attached is a rough description of the system and > its components. Much is up for discussion and redesign but at least > we have something concrete to work with now. > > Some things in particular that should probably change: > > 1) using strings to register with the core and distribute events > 2) deciding exactly what responsibilities an Event has in terms of > memory management and reference counting and distribution > > > Some things to discuss: > > 1) how free is event memory to travel outside of the basic event system > 2) how are events allocated and what are their relationships to > factories and memory pools > > > Some things to keep an eye on: > > 1) mullti-threading and stl container insertion. I'm not sure I got > everything locked up properly > > > > Any time on Monday is good for me to meet. When would be good for ya'll. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > grrr waaa > www.grahamwakefield.net > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > Graham Wakefield > wakefield@mat.ucsb.edu > www.mat.ucsb.edu/~wakefield > > > > > grrr waaa > www.grahamwakefield.net > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From alex at neisis.net Wed Aug 15 16:22:41 2007 From: alex at neisis.net (Alex Norman) Date: Wed Aug 15 16:22:55 2007 Subject: [Tdg] OSC In-Reply-To: <1079b050708151322s13bdf0a1o8dc04ffdf03f56ba@mail.gmail.com> References: <1079b050708151322s13bdf0a1o8dc04ffdf03f56ba@mail.gmail.com> Message-ID: <20070815232241.GC5968@silverninja.net> I figured I'd just send it to the list as it isn't written for mint and would therefore just be deleted from the repo as it would need considerable rework to be used for mint. So here it is (btw I'm using oscpack) the 2 things to check out are: 1) OSCEventArgument which doesn't yet include all the OSC data types but gives you an idea of what variants are. 2) The PackstreamVisitor/boost::apply_visitor(PackstreamVisitor(p), *it); which shows how visitors work [these aren't doing anything amazing at the moment]. It seems that in order to send things over OSC and construct an object based on an OSC message, we'd just require that objects [if they are OSC seralizable] have a constructor that takes a vector of OSCEventArguments.. or whatever we want to call them [using boost::variant] instead of using a visitor we could do something like: http://www.boost.org/doc/html/boost/get.html which means we could do something like: typedef vector OSCArgs; givemetheobject(vector arglist){ if (arglist.length == 3){ try { float arg0, arg1; int arg2; //i'm not sure exactly how get works arg0 = boost::get(arglist[0]); arg1 = boost::get(arglist[1]); arg2 = boost::get(arglist[2]); return new Object(arg0,arg1,arg2); } catch (boost::bad_get e){ //oops, bad args } } } so each object that is seralizeable would have a static function "givemetheobject" function [whatever it is called] and would have to register with the object factory somehow, probably just a map of object name to this static function.. //the osc message would be something like /mint/object/graphics/lineevent x y z //or we could decide on the scheme ObjectFactory::GetObjectFromOSCOrSomeBetterName(oscMessage){ string classname = getClassName(oscMessage); if(classname is in myMap){ return myMap[classname].givemetheobject(oscMessage.args); } } -Alex On 0, Wesley Smith wrote: > Hey Alex, > Could you drop your OSC stuff you showed us on Monday into the > suppository? I'd like to check out your design in more detail and see > how it could possibly be applied to generic event arguments for the > generic event constructor. > > thanks, > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -------------- next part -------------- A non-text attachment was scrubbed... Name: oscevent.cpp Type: text/x-c++src Size: 2327 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/30e73ed1/oscevent.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: oscevent.hpp Type: text/x-c++hdr Size: 1619 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070815/30e73ed1/oscevent-0001.bin From lists at grahamwakefield.net Wed Aug 15 18:23:51 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Wed Aug 15 18:23:59 2007 Subject: [Tdg] Mint Event System In-Reply-To: <11441272-96D1-4CF9-B6EB-6C577C915ACD@grahamwakefield.net> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> <2E0913A1-4943-4DF4-99E8-C3263888A2C1@grahamwakefield.net> <1079b050708151502l3772d44cq202ac886a9f49b33@mail.gmail.com> <11441272-96D1-4CF9-B6EB-6C577C915ACD@grahamwakefield.net> Message-ID: <70BEF2F1-53E1-4FEE-81F8-F46BC8BE2571@grahamwakefield.net> > Hi all, > > Ok, I updated the pthread_test example in /branches, now using this > 'day in the life' approach (i.e. no mutex locking, only trylock). > With no printfs, I'm creating and destroying 400000 events across > 40 threads (allocated in one thread, deleted in another), in about > a second, using an type-agnostic wrapper of Wes' memory pool per > thread. Probably good for this code to be tested on other machines > and see if you can spot any glaring mistakes. > > I think this is safe, except I'm not sure what happens if we blow > the stack of the memory pool. Course, its hard to make a realistic > test. > > Also, for 'unmanaged' threads, right now I resorted to malloc and > free again, but we could have a shared memory pool that is mutexed > all over the place. Not sure what would be faster really. > > Wes: I might be busy tomorrow, maybe Friday? I did the queue > popping/pushing as you suggest, and double-buffered the recyler > queue (this did noticeably help). > > G > > On Aug 15, 2007, at 3:02 PM, Wesley Smith wrote: > >> I'm not in CNSI today but I could be tommorrow to discuss this and >> figure out the brain stuff. The day in a life description sounds >> good. Here was my technique for recycling: >> >> >> On Recycle: >> **objects to be recycled are held in a std::queue >> - for each object in the queue >> - get its pointer >> - pop it from queue >> - try to recycle it >> - on failure, push it back on the queue >> >> The queue is fast to pop and push and if things don't get recycled, >> then no biggie, it will attempt to recycle it the next time. Older >> memory blocks will also accumulate at the front of the queue (not >> that >> this really matters, but is kind of a nice consequence). >> >> wes >> >> On 8/15/07, Graham Wakefield wrote: >>> >>> Thing is, the list of queues would not be static, i.e. when a new >>> thread is >>> created (or removed), and thus would itself need locking, plus >>> every thread >>> has a queue for every other. >>> >>> Does this scenario work?: >>> >>> class ManagedThread { >>> threadId // the thread it manages >>> MemoryPool // the memory pool for this thread >>> vector Deleted // objects 'deleted' in this thread >>> vector Recycler // objects ready for memory recycling >>> in this >>> thread's Pool >>> ... >>> } >>> >>> class Object { >>> ManagedThread * mOwner; // ManagedThread in which it was >>> created, or NULL >>> ... >>> } >>> >>> A day in the life of an Object: >>> >>> ManagedThread 1 creates Object a: >>> finds that ManagedThread1 is managed and allocates from >>> MemoryPool 1 (no >>> locking) >>> ManagedThread 2 tries to delete Object a: >>> finds that ManagedThread2 is managed and so places it on Deleted >>> 2 (no >>> locking) >>> >>> emptyTrash happens in ManagedThread 2: >>> checks Deleted: finds Object a, belongs to ManagedThread 1: >>> attempts to put in Recycler 1 (trylocked with recycler-mutex) >>> checks Recycler: nothing >>> >>> emptyTrash happens in ManagedThread 1: >>> checks Deleted: nothing >>> checks Recycler: finds Object a >>> pops from Recycler and reclaims to MemoryPool 1 (trylocked with >>> recycler-mutex) >>> >>> This method never calls mutex_lock, and only requires that >>> emptyTrash is >>> called periodically in every managed thread. This could be >>> automated in the >>> delete() call itself, by for example triggering emptyTrash every >>> N times >>> delete is called, and progressing M steps (or percent) through >>> the queue and >>> recycler each time to minimize burstiness. >>> >>> Some other speedups - probably stack or whatever is better than >>> vector. >>> Delete could attempt (trylock) to place in the other thread's >>> Recycler >>> immediately, and store in local Deleted only if the trylock fails. >>> >>> Not sure what would happen if you deleted from an unmanaged thread. >>> Probably needs to go into a default Deleted queue that IS locked, >>> and >>> somehow trigger an emptyTrash call on the default Deleted queue >>> periodically >>> from the main loop. >>> >>> Pennies for thoughts? >>> >>> Are you in CNSI? >>> >>> >>> grrr waaa www.grahamwakefield.net From wesley.hoke at gmail.com Wed Aug 15 18:51:52 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 18:52:00 2007 Subject: [Tdg] Mint Event System In-Reply-To: <70BEF2F1-53E1-4FEE-81F8-F46BC8BE2571@grahamwakefield.net> References: <1079b050708120133o45680ddbree9c7bec2d1247ba@mail.gmail.com> <73672298-6565-4093-AAB3-62A6981E4978@grahamwakefield.net> <1079b050708151347u2865583r69f8612ead5ac4d1@mail.gmail.com> <2E0913A1-4943-4DF4-99E8-C3263888A2C1@grahamwakefield.net> <1079b050708151502l3772d44cq202ac886a9f49b33@mail.gmail.com> <11441272-96D1-4CF9-B6EB-6C577C915ACD@grahamwakefield.net> <70BEF2F1-53E1-4FEE-81F8-F46BC8BE2571@grahamwakefield.net> Message-ID: <1079b050708151851g47619cf0x74db073f2cf42e06@mail.gmail.com> Sure. I can be around on friday. Will take a look at the code in the mean time. Thanks for getting this done! wes On 8/15/07, Graham Wakefield wrote: > > Hi all, > > > > Ok, I updated the pthread_test example in /branches, now using this > > 'day in the life' approach (i.e. no mutex locking, only trylock). > > With no printfs, I'm creating and destroying 400000 events across > > 40 threads (allocated in one thread, deleted in another), in about > > a second, using an type-agnostic wrapper of Wes' memory pool per > > thread. Probably good for this code to be tested on other machines > > and see if you can spot any glaring mistakes. > > > > I think this is safe, except I'm not sure what happens if we blow > > the stack of the memory pool. Course, its hard to make a realistic > > test. > > > > Also, for 'unmanaged' threads, right now I resorted to malloc and > > free again, but we could have a shared memory pool that is mutexed > > all over the place. Not sure what would be faster really. > > > > Wes: I might be busy tomorrow, maybe Friday? I did the queue > > popping/pushing as you suggest, and double-buffered the recyler > > queue (this did noticeably help). > > > > G > > > > On Aug 15, 2007, at 3:02 PM, Wesley Smith wrote: > > > >> I'm not in CNSI today but I could be tommorrow to discuss this and > >> figure out the brain stuff. The day in a life description sounds > >> good. Here was my technique for recycling: > >> > >> > >> On Recycle: > >> **objects to be recycled are held in a std::queue > >> - for each object in the queue > >> - get its pointer > >> - pop it from queue > >> - try to recycle it > >> - on failure, push it back on the queue > >> > >> The queue is fast to pop and push and if things don't get recycled, > >> then no biggie, it will attempt to recycle it the next time. Older > >> memory blocks will also accumulate at the front of the queue (not > >> that > >> this really matters, but is kind of a nice consequence). > >> > >> wes > >> > >> On 8/15/07, Graham Wakefield wrote: > >>> > >>> Thing is, the list of queues would not be static, i.e. when a new > >>> thread is > >>> created (or removed), and thus would itself need locking, plus > >>> every thread > >>> has a queue for every other. > >>> > >>> Does this scenario work?: > >>> > >>> class ManagedThread { > >>> threadId // the thread it manages > >>> MemoryPool // the memory pool for this thread > >>> vector Deleted // objects 'deleted' in this thread > >>> vector Recycler // objects ready for memory recycling > >>> in this > >>> thread's Pool > >>> ... > >>> } > >>> > >>> class Object { > >>> ManagedThread * mOwner; // ManagedThread in which it was > >>> created, or NULL > >>> ... > >>> } > >>> > >>> A day in the life of an Object: > >>> > >>> ManagedThread 1 creates Object a: > >>> finds that ManagedThread1 is managed and allocates from > >>> MemoryPool 1 (no > >>> locking) > >>> ManagedThread 2 tries to delete Object a: > >>> finds that ManagedThread2 is managed and so places it on Deleted > >>> 2 (no > >>> locking) > >>> > >>> emptyTrash happens in ManagedThread 2: > >>> checks Deleted: finds Object a, belongs to ManagedThread 1: > >>> attempts to put in Recycler 1 (trylocked with recycler-mutex) > >>> checks Recycler: nothing > >>> > >>> emptyTrash happens in ManagedThread 1: > >>> checks Deleted: nothing > >>> checks Recycler: finds Object a > >>> pops from Recycler and reclaims to MemoryPool 1 (trylocked with > >>> recycler-mutex) > >>> > >>> This method never calls mutex_lock, and only requires that > >>> emptyTrash is > >>> called periodically in every managed thread. This could be > >>> automated in the > >>> delete() call itself, by for example triggering emptyTrash every > >>> N times > >>> delete is called, and progressing M steps (or percent) through > >>> the queue and > >>> recycler each time to minimize burstiness. > >>> > >>> Some other speedups - probably stack or whatever is better than > >>> vector. > >>> Delete could attempt (trylock) to place in the other thread's > >>> Recycler > >>> immediately, and store in local Deleted only if the trylock fails. > >>> > >>> Not sure what would happen if you deleted from an unmanaged thread. > >>> Probably needs to go into a default Deleted queue that IS locked, > >>> and > >>> somehow trigger an emptyTrash call on the default Deleted queue > >>> periodically > >>> from the main loop. > >>> > >>> Pennies for thoughts? > >>> > >>> Are you in CNSI? > >>> > >>> > >>> > > grrr waaa > www.grahamwakefield.net > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From wesley.hoke at gmail.com Wed Aug 15 22:48:57 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 22:49:04 2007 Subject: [Tdg] super/sub class copy Message-ID: <1079b050708152248v4606277xd04757b8fc4dcd5f@mail.gmail.com> Anyone know how to do the following in C++: Given a superclass (Super) I want to construct a subclass (Sub) from it. Sub is basically a shell wrapper around Super with no new data but more methods. I want something like class Sub : public Super { public: Sub(Super &super); }; What do I have to do in the constructor so that things work out? wes From wesley.hoke at gmail.com Wed Aug 15 22:56:35 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Aug 15 22:56:42 2007 Subject: [Tdg] C++0x Message-ID: <1079b05070815225