Menu
▾
▴
elj-devel
|
From: V K. <bir...@in...> - 2003-02-26 08:01:05
|
From: "Marcio Marchini" <mq...@ma...> >>>>>>> I think we should have a mix of ethreads and epthreads. I mean a new project, as I said, mixing both code bases into 1 uniform approach. Use posix threads in all platforms but Windows, use Windows threads directly. Common API to user programs. >>>>>>>> POSIX threads is avilable for Win32 as well. checkout http://sources.redhat.com/pthreads-win32 cheers, -Krish Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! |
|
From: Marcio M. <mq...@ma...> - 2003-02-26 13:33:05
|
| POSIX threads is avilable for Win32 as well. | checkout http://sources.redhat.com/pthreads-win32 I know, but last time I looked at it (1 year qago, I admit) its status under windoze was terrible. Maybe it's good enough nowadays that it can be used. Not sure about LGPL. Does it mean you have to open source anything you do with it, preventing commercial products ? I hope not. marcio |
|
From: Geoff E. <gel...@pr...> - 2003-02-26 23:03:58
|
Hi All, On Wed, 26 Feb 2003, Marcio Marchini wrote: > | POSIX threads is avilable for Win32 as well. > | checkout http://sources.redhat.com/pthreads-win32 > > > I know, but last time I looked at it (1 year qago, I admit) its status under > windoze was terrible. Maybe it's good enough nowadays that it can be used. Another consideration is that the resulting win32 lib/dll/h files should be compatible with our SE backend C compiler of choice, that being lcc-win32. Do we have any new C gurus on the list who can help progress this work. Starting links include: * http://sourceforge.net/mailarchive/message.php?msg_id=3759890 * http://sourceforge.net/mailarchive/message.php?msg_id=3882038 Any help here would definitely appreciated as it this topic has come up a number of times recently (and also in the distant past). Regards .. Geoff > Not sure about LGPL. Does it mean you have to open source anything you do > with it, preventing commercial products ? I hope not. > > > marcio |
|
From: Marcio M. <mq...@ma...> - 2003-02-26 23:41:30
|
Using Threads requires the Boehm GC, so I think the ELJ_MEMORY versus MEMORY problem has to be solved first. Eiffel code should be the same if you are using the SE GC or the Boehm GC. I suggesting coming up with a problem report for SE first, and propose a fix for them. Once users can easily switch from one GC to the other at cmd-line, then Threading is a matter of interfacing to those libs, and we already have some initial code. marcio | -----Original Message----- | From: Geoff Eldridge [mailto:gel...@pr...] | Sent: February 26, 2003 6:03 PM | To: Marcio Marchini | Cc: elj...@li... | Subject: RE: RE: threads (was RE: [elj-devel] Choosing a network lib) | | | Hi All, | | On Wed, 26 Feb 2003, Marcio Marchini wrote: | | > | POSIX threads is avilable for Win32 as well. | > | checkout http://sources.redhat.com/pthreads-win32 | > | > | > I know, but last time I looked at it (1 year qago, I admit) its status under | > windoze was terrible. Maybe it's good enough nowadays that it can be used. | | Another consideration is that the resulting win32 lib/dll/h files should | be compatible with our SE backend C compiler of choice, that being | lcc-win32. | | Do we have any new C gurus on the list who can help progress this work. | Starting links include: | | * http://sourceforge.net/mailarchive/message.php?msg_id=3759890 | * http://sourceforge.net/mailarchive/message.php?msg_id=3882038 | | Any help here would definitely appreciated as it this topic has come up | a number of times recently (and also in the distant past). | | Regards .. Geoff | | > Not sure about LGPL. Does it mean you have to open source anything you do | > with it, preventing commercial products ? I hope not. | > | > | > marcio | |
|
From: Geoff E. <gel...@pr...> - 2003-02-27 01:03:56
|
On Wed, 26 Feb 2003, Marcio Marchini wrote: > > Using Threads requires the Boehm GC, so I think the ELJ_MEMORY versus MEMORY > problem has to be solved first. Eiffel code should be the same if you are using > the SE GC or the Boehm GC. Is this the case. We have standard common classes for mem: http://cvs.sf.net/cgi-bin/viewcvs.cgi/elj/elj-2002/lib/cmn/eiffel/base/mem/ The xace/geant file combination selects the appropriate class for boehm/std gc compilation. With the many ELJ libs and apps, we don't appear to have a problem switching. Just use ELJ_MEMORY. Sorry if I am misunderstanding what you are saying. My knowledge of this is rather limited. > I suggesting coming up with a problem report for SE > first, and propose a fix for them. It would be worth submitting a problem report on this matter. Olivier Zendra - http://www.loria.fr/~zendra/ - is now back at Loria. He implemented the SE Garbage Collector and has published much on the topic: * Compiler Support to Customize the Mark and Sweep Algorithm http://www.loria.fr/~zendra/publications/ismm98.pdf * see also his PhD (for French speakers) .. http://www.loria.fr/~zendra/publications/these.pdf elj-girls has proven that there is problems with the SE GC for long running apps. The usage of the Boehm collector has removed this problem and was the reason why Uwe has gone to such trouble to integrate Boehm GC into the ELJ project. > Once users can easily switch from one GC to the other at cmd-line, then > Threading is a matter of interfacing to those libs, and we already have some > initial code. We already have this functionality with the standard geant files that come with ELJ. Eg: --8<-- C:\nem\work\eiffel\ic-report>geant usage: geant compile -- default version as configured in target 'init' geant compile_boost -- english 'boost' version geant compile_assert -- english version, all assertions enabled geant compile_trace -- debugger version geant compile_boehm -- 'boost' version with BDW gc geant clean -- remove intermediary generated files geant clobber -- remove all generated files -->8-- Regards .. Geoff > marcio [..] |
|
From: Marcio M. <mq...@ma...> - 2003-02-27 02:32:34
|
| > Using Threads requires the Boehm GC, so I think the ELJ_MEMORY | versus MEMORY | > problem has to be solved first. Eiffel code should be the same if | you are using | > the SE GC or the Boehm GC. | | Is this the case. We have standard common classes for mem: | | http://cvs.sf.net/cgi-bin/viewcvs.cgi/elj/elj-2002/lib/cmn/eiffel/base/mem/ | | The xace/geant file combination selects the appropriate class for | boehm/std gc compilation. With the many ELJ libs and apps, we don't appear | to have a problem switching. Just use ELJ_MEMORY. Sorry if I am | misunderstanding what you are saying. My knowledge of this is rather | limited. But it is sort of bogus to force everybody to pre-req ELJ. YAESOCKETS would have to pre-req ELJ (because yaesockets inherits from MEMORY, so I'd have to change the code to inherit from ELJ_MEMORY). GOBO would have to pre-req ELJ. EPOSIX, ditto. And so on. Basically everybody inheriting from MEMORY to override dispose would have to change their code to inherit from ELJ_MEMORY. That is bogus. The trick has to be in SE's memory class. Unless I missed something on how it works today ? | | > I suggesting coming up with a problem report for SE | > first, and propose a fix for them. | | It would be worth submitting a problem report on this matter. Olivier | Zendra - http://www.loria.fr/~zendra/ - is now back at Loria. He | implemented the SE Garbage Collector and has published much on the topic: I can't enter the problem report because I don't fully understand the changes made. I my opinion SE has to have a -boehmgc flag and have code generated for teh MEMORY/dispose trick. | We already have this functionality with the standard geant files that | come with ELJ. Eg: | | --8<-- | C:\nem\work\eiffel\ic-report>geant | usage: | geant compile -- default version as configured in target 'init' | geant compile_boost -- english 'boost' version | geant compile_assert -- english version, all assertions enabled | geant compile_trace -- debugger version | geant compile_boehm -- 'boost' version with BDW gc Again, this will plug the right "dispose" only for those classes using ELJ_MEMORY. For example, if I use EPOSIX classes + GOBO classes + YAESOCKETS classes (which do not pre-req ELJ), which may be inheriting from MEMORY to override dispose to free resources, these classes will not have the facility in ELJ_MEMORY. So, I believe none of these disposes are going to run, right ? So, you may get leaks etc (depending oh how serious the dispose work is). rather than force everybody to inherit from ELJ_MEMORY, you want to fix teh runtime/compiler to have better Boehm support, IMHO. marcio |
|
From: Uwe S. <us...@on...> - 2003-02-27 04:05:33
|
Hi people, On Thursday 27 February 2003 00:41, Marcio Marchini wrote: > Using Threads requires the Boehm GC, so I think the ELJ_MEMORY versus > MEMORY problem has to be solved first. Eiffel code should be the same if > you are using the SE GC or the Boehm GC. I suggesting coming up with a > problem report for SE first, and propose a fix for them. They will not accept it as something to fix, because it is a pure library question. You want to interface an external library, the BDW GC? So go ahead and do it, this has nothing to do with the compiler. That will be their answer and they are right. The main problem is, I think, that my naming choice was not that smart. Think of SE's property to choose the class it finds first on the loading path, so I should simply keep the name MEMORY and no more probs at all. Yes, I think that's the way we'll go: make the BDW lib an external lib usable without any further linkage to ELJ and name the class in question MEMORY, which means that I will declare ELJ_MEMORY as obsolete. Thougts? Regards Uwe |
|
From: Marcio M. <mq...@ma...> - 2003-02-27 04:29:33
|
| They will not accept it as something to fix, because it is a pure library | question. You want to interface an external library, the BDW GC? So go ahead | and do it, this has nothing to do with the compiler. That will be their | answer and they are right. | The main problem is, I think, that my naming choice was not that smart. Think | of SE's property to choose the class it finds first on the loading path, so I | should simply keep the name MEMORY and no more probs at all. Yes, I think | that's the way we'll go: make the BDW lib an external lib usable without any | further linkage to ELJ and name the class in question MEMORY, which means | that I will declare ELJ_MEMORY as obsolete. | Thougts? | If I can, at compile-time, use your MEMORY class instead of SE's and not have to change my code, that's the right answer. Of course your MEMORY class has to be maintained to be in sync with the latest&greatest MEMORY from the SE distro (assuming you copied/pasted some code). I still think MEMORY & GC is special enough to need compiler support though. But your idea is a 99% solution I guess. marcio |
|
From: Geoff E. <gel...@pr...> - 2003-02-27 04:35:20
|
Hi, I think Uwe's suggestion is the correct approach. Should not be too hard to implement also. Thanks to all those who have participated in this discussion. Regards .. Geoff On Thu, 27 Feb 2003, Uwe Sander wrote: > On Thursday 27 February 2003 00:41, Marcio Marchini wrote: > > Using Threads requires the Boehm GC, so I think the ELJ_MEMORY versus > > MEMORY problem has to be solved first. Eiffel code should be the same if > > you are using the SE GC or the Boehm GC. I suggesting coming up with a > > problem report for SE first, and propose a fix for them. > > They will not accept it as something to fix, because it is a pure library > question. You want to interface an external library, the BDW GC? So go ahead > and do it, this has nothing to do with the compiler. That will be their > answer and they are right. > The main problem is, I think, that my naming choice was not that smart. Think > of SE's property to choose the class it finds first on the loading path, so I > should simply keep the name MEMORY and no more probs at all. Yes, I think > that's the way we'll go: make the BDW lib an external lib usable without any > further linkage to ELJ and name the class in question MEMORY, which means > that I will declare ELJ_MEMORY as obsolete. > Thougts? > > > Regards > > Uwe > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > elj-devel mailing list > elj...@li... > https://lists.sourceforge.net/lists/listinfo/elj-devel > |
|
From: Uwe S. <us...@on...> - 2003-02-27 04:45:14
|
Hmmmmm, On Thursday 27 February 2003 05:34, Geoff Eldridge wrote: > Thanks to all those who have participated in this discussion. Not done right now ... Early in the morning here, so I missed an important point: it does not work w/o calling a special routine to register the dispose call within the BDW, so I think my approach was simply wrong :-(. We need the creation routine of ELJ_MEMORY and I have no idea how to achieve this with a little c_inline_c magic. Regards Uwe |
|
From: Marcio M. <mq...@ma...> - 2003-02-27 11:32:52
|
| Early in the morning here, so I missed an important point: it does not work | w/o calling a special routine to register the dispose call within the BDW, so | I think my approach was simply wrong :-(. We need the creation routine of | ELJ_MEMORY and I have no idea how to achieve this with a little c_inline_c | magic. I entered a problem report (feature request) for SE: http://smartzilla.loria.fr/show_bug.cgi?id=165 If anybody can add more details to it, please do so. Thanks, marcio |
|
From: Marcio M. <mq...@ma...> - 2003-02-27 11:46:40
|
Already tagged as a duplicate of Berend's problem report http://smartzilla.loria.fr/show_bug.cgi?id=158 marcio | | Early in the morning here, so I missed an important point: it does not work | | w/o calling a special routine to register the dispose call within | the BDW, so | | I think my approach was simply wrong :-(. We need the creation routine of | | ELJ_MEMORY and I have no idea how to achieve this with a little c_inline_c | | magic. | | | I entered a problem report (feature request) for SE: | http://smartzilla.loria.fr/show_bug.cgi?id=165 | | If anybody can add more details to it, please do so. | | Thanks, | | marcio |
|
From: <pla...@fr...> - 2003-02-28 23:43:02
|
Geoff Eldridge wrote : Hi Dears, > Do we have any new C gurus on the list who can help progress this > work. Starting links include: > > * http://sourceforge.net/mailarchive/message.php?msg_id=3759890 > * http://sourceforge.net/mailarchive/message.php?msg_id=3882038 > > Any help here would definitely appreciated as it this topic has > come up a number of times recently (and also in the distant past). I'm looking if we can use epthread under Windows. Ethread uses the internal SE GC so it can't work. The test sample included in epthread works with the pthread-win32 lib, lcc-win32 and SmartEiffel with boehm gc. I've made only little changes into epthread (just because it uses obsolete features). The difficulty is to understand how to link all this stuff. I have to make more tests to see if it really works. May be (i hope) it could be a solution to have threads with Eiffel under Windows and Posix. Regards. -- Patrick |
|
From: <pla...@fr...> - 2003-03-01 17:10:27
|
Patrick Lamaizi=E8re wrote Hi all, [epthread with pthread-win32] > I have to make more tests to see if it really works. May be (i > hope) it could be a solution to have threads with Eiffel under > Windows and Posix. It doesn't work and it can't work, BDW GC must know when we create a=20 thread, if the creation is into a dll, it don't know and it freezes.:-( BDW uses a #define to hook the win32 CreateThread Api. I will look how to use the epthread interface with the Windows API. Regards. --=20 Patrick |
|
From: Uwe S. <us...@on...> - 2003-03-01 18:31:19
|
Hi Patrick, On Saturday 01 March 2003 18:10, Patrick Lamaizière wrote: > It doesn't work and it can't work, BDW GC must know when we create a > thread, if the creation is into a dll, it don't know and it freezes.:-( It knows, because it has THREAD_ATTACH in its Dll entry func. Why don't you save your current work on SF (or wherever you like) and let us help you? You can even let this one run under the hood of elj. Just an offer. Regards Uwe |
|
From: Marcio M. <mq...@ma...> - 2003-03-01 19:18:44
|
| It knows, because it has THREAD_ATTACH in its Dll entry func. Why don't you | save your current work on SF (or wherever you like) and let us help you? You | can even let this one run under the hood of elj. Just an offer. Both are already under CVS under elj-eiffel: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/elj-eiffel/ It seems Patrick is going to move ethread forward, which is good. Patrick, can you commit your changes to ethread ? I think the next big problem will be the once features that are not thread-safe in the lib. A bunch of buffers, for example, to compute the printString of objects. I mean things like, for example, these 2 features in STRING feature {NONE} string_buffer: STRING is -- Private, temporary once buffer. once create Result.make (256) end -- string_buffer split_buffer: ARRAY [STRING] is once create Result.with_capacity (4, 1) end -- split_buffer It just won't work well with Threads, and I think that's why Miguel de Oliveira defined its changes so that once would be per-Thread. I'd rather have a choice, and see better libs. marcio |
|
From: <pla...@fr...> - 2003-03-02 11:13:46
|
Marcio Marchini wrote : > It seems Patrick is going to move ethread forward, which is > good. Yes, i have to mix ethread with epthread. As you said, some posix #define are missing in ethread. > Patrick, can you commit your changes to ethread ? No problem (thanks for the offer Uwe), when i will have something to commit. I don't want to commit something that can't work. I want to check first if we can use threads with SE. I have to read all the posts about threads into the SmartEiffel list. > I think the next big problem will be the once features that > are not thread-safe in the lib. A bunch of buffers, for example, to > compute the printString of objects. I mean things like, for example, > these 2 features in STRING Yes it is a big problem. -- Patrick |
|
From: <pla...@fr...> - 2003-03-04 21:10:18
|
I wrote : >> I think the next big problem will be the once features that >> are not thread-safe in the lib. A bunch of buffers, for example, >> to compute the printString of objects. I mean things like, for >> example, these 2 features in STRING > > Yes it is a big problem. The big big problem is, if i understand well the SE team, that the code generated by SE is not thread-safe itself. So i think it is not a good idea to work on threads now :-( It seams we have to wait for scoop. -- Patrick |
Thanks for helping keep SourceForge clean.
X