On Fri, 2004-01-23 at 01:19, Kosta Tachtevrenidis wrote: > I want to say that I think the Thread class approach might be less > painfull but equally effective. I assume the Thread class would have to > do all the scheduling and the preemption. Am I right?
Through calls to the POSIX thread library routines, yes - but I think all the scheduling and preemption is handled down there (inside the posix library). Unless the Thread class can be written directly in C/C++, someone will have to provide wrappers so the important POSIX thread calls can be made from Unicon - that part shouldn't be hard, there's not a lot of data going back and forth on most of the calls, just control. (There are also packages that make using POSIX threads easier to use - OmniORB has one, for example, though I'm sure there are others more suitable here. Building on top of such a package instead of directly on top of POSIX would probably make life easier, if you can find one with a compatiple license.) Wrapping the underlying calls would also permit the writing code directly on top of the underlying calls outside the Thread class, but I personally think doing so will cause more problems than one might imagine and so would tend to want to discourage that practice - hence my own preference for wanting to see Thread implemented directly in C/C++...). Even so, using Unicon wrappers for POSIX should probably be the first implementation, as that's the most straightforward - I don't imagine anyone has really looked at trying to write Unicon classes in C/C++! (Until *that* issue is addressed, there's no point in trying to do a 'native' Thread class implementation - and people may find the 'temporary' implementation better, anyway!) Letting the real work be done by the POSIX thread library has several advantages, including perhaps making it easier to take advantage of the NPTL support showing up (newer versions of SUN's Java, for example, take advantage of NPTL in the newer glibc packages - the result is impressive on heavily threaded applications). As Clint said, the hard part is probably going through the Unicon runtime library and making it thread safe. > Also about making unicon work with jcont, it sounds easy but it might > too good to be true. Not knowing about jcont, what are the differences > other than the apparent java involvement? Someone with more knowledge of jcont's implementation will have to comment here. For some reason I've always been uneasy about jcont, but without any solid basis for being so, having never played with it... -- Steve Wampler <[EMAIL PROTECTED]> ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
