Re: Patch submission gone missing?
I submitted a patch yesterday to [EMAIL PROTECTED], and received the automated response (the ID is [perl #24789]), but it doesn't seem to have been forwarded to the mailing list. Is something up with the tracking system? Nothing is up. It's in the moderation queue. The list moderator is probably still recovering -- it is a holiday. Please give him a break. -R
Re: Patch submission gone missing?
On Jan 1, 2004, at 11:31 PM, Robert Spier wrote: I submitted a patch yesterday to [EMAIL PROTECTED], and received the automated response (the ID is [perl #24789]), but it doesn't seem to have been forwarded to the mailing list. Is something up with the tracking system? Nothing is up. It's in the moderation queue. The list moderator is probably still recovering -- it is a holiday. Please give him a break. I didn't realize there was moderation. (How was spam getting through?) JEff
Re: Patch submission gone missing?
I didn't realize there was moderation. (How was spam getting through?) Spam was getting through because when I upgraded RT, I didn't re-insert some of my envelope massaging magic, which meant that spam was looking as if it was coming from a valid address, when it really wasn't. Once I re-inserted that magic, the spam disappeared. -R
Re: Problem during make test
Dan Sugalski wrote: [EMAIL PROTECTED] pbin]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1) Yeah, that was the one, unfortunately. Try disabling the JIT during configuration and seeing if that takes care of the problem. If so, we'll need to update configure to do that automatically, since I think we're going to end up running into this for years. :( No Joy. I will upgrade gcc and see what happens. Harry Jackson
Re: threads and shared interpreter data structures
Leopold Toetsch [EMAIL PROTECTED] wrote: 3) a separate array for the JITed method stubs, which are per interpeter and only if the platform can generate such stubs on the fly. Done now. JITted NCI methods are now enabled again but only i386 has the necessary interface code in jit/*. leo
Re: Object system
Luke Palmer [EMAIL PROTECTED] wrote: I notice that ParrotObject only has [get|set]_integer_keyed. I assume we intend to make those for the rest of the data types. Yep. Albeit before continuing here filling the blanks, I'd really like to have attribute naming/mangling clarified. The pmc doesn't depend on that, but tests do :) Also, in order to support anonymous classes, I'd like the method table to be in the class object itself, as opposed to in mangled globals. Is this also something I could tackle? Its again the problem of name mangling. Melvin's proposal WRT class syntax seems to imply, that imcc takes care of bundling methods with their classes, but I'm not sure, how the anonymous case will be done. Thanks, Luke leo
Re: cvs commit: parrot/src call_list.txt utils.c
Dan Sugalski [EMAIL PROTECTED] wrote:
Add in support for the T and L NCI types. (char pointer array and
long array)
These should IMHO be no separate signatures, but be expressed in terms
of the 'p' signature and use an appropriate {Un,}ManagedStruct PMC[1]. If
we start passing all these array types with distinct signatures, we will
ran out off signature chars soon - and its really non-trivial to
implement all these in JIT.
leo, just my 2c
[1] docs/pmc/struct.pod already exists :)
char *[] isn't handled yet though
[mhx-perl@gmx.net: Re: XS and strings]
Another thing to scan for Kwalitee? [probably quite hard] Nicholas Clark - Forwarded message from Marcus Holland-Moritz [EMAIL PROTECTED] - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Authenticated: #13357003 Date: Fri, 2 Jan 2004 17:36:27 +0100 From: Marcus Holland-Moritz [EMAIL PROTECTED] To: Alberto Manuel Brandão Simões [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: XS and strings In-Reply-To: [EMAIL PROTECTED] X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Spam-Check-By: one.develooper.com X-Spam-Status: No, hits=-1.0 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.44 X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ On 2004-01-02, at 12:51:04 +, Alberto Manuel Brandão Simões wrote: On Thu, 2004-01-01 at 21:50, Marcus Holland-Moritz wrote: First, don't pass NULL as RETVAL. This looks to me like you want to return an undefined value. Use XSRETURN_UNDEF instead. True. I was browsing the CPAN yesterday. A lot of people seem to assume that it's valid to return NULL as an AV*. It isn't. It even causes a segmentation violation. -- Power corrupts. And atomic power corrupts atomically. - End forwarded message -
Enhancements for the debugger
As I studiously ignore all the thread threads (Ah, deadlines--gotta love 'em) I'm bumping into a number of things in the system as it currently stands that could use fixing/enhancement/rethinking. At the moment, the thing is the debugger, trace mode, and/or the compiler. First off, trace mode is just darned useful, and I'm pretty sure having it around has shaved a day or two off the project I'm working on. Kudos, and I owe a number of people thanks, a beer, and maybe a pie. (Mmmm, pie! Stationary, though) Having said that... I think it's about time to get the annotated metadata stuff spec'd out, possibly in conjunction with annotated listings from imcc. What I'd like, ultimately, is to have the source file/line information spat out when tracing, as well as getting a listing file from IMCC such that I can look at it and see which line of the source corresponds to the op at offset 684 (or whatever) when trace mode is running. I know Melvin's working on gutting and rewriting the imcc bits, so it may be better to dig into the metadata bits first. Folks uninterested (or feeling unqualified) in participating in the thread thread might want to jump in here. Ultimately the metadata info will allow targeting the source file and line that an instruction's from, regardless of the language it came from, so keep flexibility in mind. (Speed isn't essential here, since the info will generally be used only in extraordinary circumstances--tracing or error messages--where a millisecond or three extra's no big deal) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC debugging?
Dan Sugalski [EMAIL PROTECTED] wrote: Does IMCC have any good debugging hooks inside it? I'm running into a problem where one of my subs is thinking it's an old-style (params on stack) sub That's very probably coming from comments before/inmidst .param directives. The parser currently doesn't handle that yet IIRC. And may be: parrot -E foo.imc | less # preprocessor output parrot -o- foo.imc | less # PASM output leo
Re: Threads Design. A Win32 perspective.
On Thu, 01 Jan 2004 21:32:22 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote: UG Uri Guttman NS Nigel Sandever. (Mostly not reproduced here!) NS REENTRANCY UG this is true for c level threads but not necessarily true for VM level UG threads. f the VM is atomic at its operation level and can't be UG preempted (i.e. it is not using kernel threads with time slicing), One of the major points of what I am (was?) proposing, is that there would be a 1:1 mapping between VM threads and kernel threads. The second point is that atomic operation of the VM thread does not imply that they cannot be preempted. It only means that when one VM thread is preempted by the scheduler, no other thread that is waiting to enter the same critical section as the first thread is in, will be scheduled (by the scheduler), until the first thread exits that critical section. UG then UG it could use thread unsafe calls (as long as it keeps those silly static UG buffers clean). The point about avoiding calling the CRT directly from the main bulk of the code does not preclude the use of (suitably thread-aware) CRT calls completely. The idea is to acknowledge that A) Not all CRT's are equally well crafted or complete. B) Thread-aware CRTs are not available with all compilers for all platforms. By writing the main bulk of the code in terms of a virtual CRT using macros, the main bulk of the code becomes platform independent. The only change required porting the code to different platforms is to write a set of suitable expansions for the macros for each platform/ compiler. Where the available CRT is up to the job, the macros expand directly to the underlying CRT call. Where they are not, a suitable alternative can be written that bypasses the CRT and goes directly to runtime. As an example: Compiling P5 with Borland 5.5 for NT, I encountered the restriction that the Borland runtime didn't support (fseek) or (f)tell on files 4GB. The underlying platform does, and it was relatively trivial to replace the calls to the CRT functions with appropriate NT syscalls and so enable both USE_LARGE_FILES and PERLIO. The only difficulty was that instead of being able to make the changes in a single place, it was necessary to make essentially the same change in 3 or 4 different files. To compound matters, the modifications required conditional compilation directives at all 4 places, and these had to be interspersed with other #ifdefs for other platforms and other purposes. The idea was to avoid this morass of conditional compilation and copypaste coding by pushing the conditional directives in the main code to a single #if defined( THIS_PLATFORM ) #include this_platform_crt.h Within that header would be a simple set of #ifdefs to include compiler specific header files. And within those, all the CRT macro expansions. Thus, I sought to ease both porting and maintenance. It would also become possible to add virtual syscall definitions to the high level code, and expand them differently, perhaps radically so, on a platform by platform basis. In essence, creating a Virtual OS for the VM. UG parrot will (according to dan) use one interpreter per UG VM thread and those may run on kernel threads. From what I have read, the decision as to whether each VM thread also got a separate interpreter was one of the things Dan was opening up to discussion? Personally, with the perspective of (the forkless) NT platform, and my experience with trying to make good use of both p5's 5005thread and ithread implementations, I am completely against the idea of VM threads having a 1:1 relationship with interpreters. The runtime costs of duplicating all shared data between interpreters, tying all shared variables, added to the cost of locking, throw away almost all of the benefit of using threads. Combine that overhead with the restrictions of a) No shared references therefore: b) No shared objects, therefore: c) No shared methods. d) No shared compound data structures. And the only hope for multiprocessing becomes forking, which WIn32 doesn't support natively. And which, without the benefits of process level COW performed by the kernel, results in a kludged emulation of a non-native facility that will never be usable in any real sense of the word. UG it may be possible to UG disable preemption and/ or time slicing so the VM threads will be atomic UG at the VM operation level and then we don't have to worry as much about UG thread unsafe libs. I was trying to demonstrate that there is no need to disable the scheduler in order for VM threads to be achieve atomic VM level operations. UG but i gather that people want real preemption and UG priorities and time slicing so that idea may be moot. Yes. I am one of them:) UG but on most UG platforms that support kernel threads there are thread safe versions of UG most/ all the c lib stuff. As I said above. This is true, but it is also compiler
Re: Threads Design. A Win32 perspective.
NS == Nigel Sandever [EMAIL PROTECTED] writes: NS ATOMICITY AND CRITICAL SECTIONS UG that is what i mentioned above, disabling time slicing/ preemption when UG desired. it is not just a win32 concept. hell, turning off interrupts UG during interrupt handlers goes way back! redmond just likes to rename UG stuff and act like they invented it. :) NS I cannot emphasis enough that Critical Sections are different to NS both Events and Semaphores. NS The distinction is that a critical section does not disable time NS slicing/ preemption. It prevents any thread attempting to enter an NS owned critical section from receiving a timeslice until the current NS owner relinquishes it. This means that other threads in the same process NS and other processes continue to timeslice preemptively. Only the NS thread(s) waiting to enter the specified critical section are blocked. NS There is no 'spinning' involved. it has to disable slicing/preemption if there are multiple kernel threads running that have access to that data. UG in effect it sounds like a thread shared mutex. it could be implemented UG in kernel or process space. NS They are indeed a form of mutex, but the process space state and NS avoiding the need to switch to kernel mode, is crucial, as it is NS this that makes them lighter weight than a conventional IPC Mutex. NS A CRITICAL_SECTION is a DWORD allocated in user space. It must be NS allocated by the user space code, and then initialised through a NS syscall. Once initialised, it cannot be move, copied or modified NS (directly) by the user code. NS If you have the time and inclination, there is a brief (25 line) NS description of them at NS [http://msdn.microsoft.com/library/en-us/dllproc/base/critical_section_objects.asp] UG that flag setting needs to be atomic or a mutex or similar. plain flag UG setting won't work. also the blocking has to be kernel level (so a UG kernel mutex/ semaphore is needed) so the kernel slicing will work. NS Indeed. A simple flag *is* all that is necessary to protect shared (fat) NS data structures, *if* the VMs, are the only code that could achieve NS concurrent access to the contents of the PMC, and these are already NS interlocked at the operational level. NS A PMC is an object, and the only code that can affect the state of NS that object are it's methods. The methods can only be invoked by NS the VM. Each method constitutes an (atomic) operation at the VM NS level. NS All that is required to protect an object from corruption through NS concurrent access and state change is to prevent two (or more) VMs NS trying to access the same object simultaneously. In order for the VM to NS address the PMC and must load it into a VM register, it must know where NS it is. Ie. It must have a pointer. It can use this pointer to access NS the PMC with a Bit Test and Set operation. (x86 BTS) NS [http://www.itis.mn.it/linux/quarta/x86/bts.htm] This is a CPU atomic NS operation. This occurs before the VM enters the VM operations critical NS section. ding! ding! ding! you just brought in a cpu specific instruction which is not guaranteed to be on any other arch. in fact many have such a beast but again, it is not accessible from c. and still some archs don't have it so it has to be emulated by dijkstra's algorithm. and that requires two counters and a little chunk of code. you can't bring x86 centrism into this. the fact that redmond/intel threads can make use of this instruction to do 'critical sections' is a major point why it is bad for a portable system with many architectures to be supported. NS Once the bit has been set in the PMC header by one VM, if the scheduler NS intervened exactly before the next instruction in that thread, and NS scheduled a second VM thread to run, and that VM also attempts to access NS that same PMC,the first operation it tries to perform is the same BTS NS instruction. The next instruction then tests the CF (Carry flag) and NS knows that the PMC is already in use. Hence, it then relinquishes NS (yields) the rest of its timeslice. i am well aware about test/set and atomic instructions. my point in my previous reply was that it can't be assumed to be on a particular arch. so it has to be assumed to be on none and it needs a pure software solution. sure a platform specific macro/assembler lib could be done but that is a pain as well. NS Every time the second (or subsequent) VM attempts to use a PMC NS that is already in-use, it finds the bit set and immediately NS yields. This will only happen during the interval between the NS first VM issuing the BTS, and that same VM entering the NS critsec. Once the critsec has been entered, no other VM that could NS load that PMC, would even be scheduled. yield is also a kernel specific thing and what will wake up the thread after that? it has to block on some kernel thingy and the
