merriman@ccavax.camb.com (05/27/90)
In article <O:O33R7@xds13.ferranti.com>, peter@ficc.ferranti.com (peter da silva) writes: > In article <24654.265c32f6@ccavax.camb.com>, merriman@ccavax.camb.com writes: >> You can do anything in a VMS or RSX AST that takes into consideration >> the logical concurrency issues involved in the application. Most native >> library and system services are designed to be AST-re-entrant. Some brain-dead >> C RTL implementations don't understand what this means. > > There sure was no C RTL involved when I was doing this. If it was a run-time > library problem it was in the Fortran RTL, because that's what I was running > Forth under. This was in the early '80s, and the system probably dated back > before that. > >> > Anyway, you sure couldn't longjmp out of one, at least not in 11/M. I know >> > that because I wanted to do it for a Forth implementation. > ^^^^^--- This is an important word. > >> longjump is not an RSX concept. > > Longjmp is a *language* concept, and has nothing to do with any O/S. Is longjump a language concept or a library concept? I find that the answer to this question depends on who you talk to and what is being argued. In any case, if it is a language concept then it is a C language concept, and if it is a library concept it is closely associated with the typical C run-time library. But you say you work working with Forth and Fortran so I don't see where longjump comes into the discussion at all. As this is the C language newsgroup, I jumped to the conclusion that C or the C RTL was somehow involved. > >> You must have been using something cobbled up >> to mimic UNIX behavior > > I must have. Go back and read what I wrote and tell me why I MUST HAVE > been "using something cobbled up to mimic UNIX behaviour". Let's see, I was > talking about C and Forth and RSX. Nothing to do with UNIX there. You MUST > HAVE jumped to a conclusion in the absence of evidence. Fair enough, I did jump to that conclusion and I apologize. However, I would argue that the setjump-longjump paradigm is strongly associated with the UNIX signal handling mechanism and IMHO it does not always map cleanly to other operating systems. I was simply trying to understand your statement about not being able to do system calls and such from RSX ASTs. > > This was running John James' FIG Forth for the PDP-11, with a Fortran > skeleton to avoid having to figure out how to do serial file I/O via > QIOs. (ech) And I couldn't do a QIO$W from an AST. I guess this falls > under the "takes into consideration the logical concurrency issues..." > part. > -- There is nothing in the RSX AST mechanism which prevented you from being able to do a QIOW from an AST routine. There may have been a restriction caused by using the Fortran native I/O, but it was not due to RSX or ASTs. I would normally expect to find the asynchronous form of the QIO in an AST because the AST handler will block until the QIOW completes and it is generally considered best to spend as little time in an AST handler as possible, but so long as you keep this in mind, and keep in mind what you might be clobbering in the mainline execution thread, a QIOW will work fine from an AST. In any case, what drew me into this discussion is your statement to the effect that it is not possible to do system calls from RSX ASTs. This is simply not true. Note that I do not include language-specific concepts in my definition of system calls and this may be a source of confusion. There may have been something about the Fortran I/O implementation which gave you trouble, but once again, this is not because of a problem with the AST mechanism. I did a fair bit of work with RSX Fortran during 1984 and 1985 involving code that was written somewhat earlier and I can remember no such restriction being mentioned, although most of the really hairy stuff on that system was written in MACRO. I apologize once again for jumping to the conclusion that C was somehow involved in a C newsgroup discussion. > `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> > 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> > @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf. George Merriman Cambridge Computer Associates
peter@ficc.ferranti.com (Peter da Silva) (05/27/90)
In article <24867.265eca87@ccavax.camb.com> merriman@ccavax.camb.com writes: > I apologize once again for jumping to the conclusion that C was > somehow involved in a C newsgroup discussion. Fair 'nuff. But what distressed me was the assumption that UNIX was involved in a C newsgroup discussion. This is comp.lang.c, not comp.lang.c.under.unix. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.