CN101821713A - 用于定制sip和sdp协议的用户协同例程接口 - Google Patents

Abstract

一种使用协同例程来实现BASIC程序和其中要修改(例如)SIP和SDP数据的系统中的点之间的类似函数的接口的方法。从最终用户的观点来看该协同例程接口是直观的，并且从系统设计者的观点来看实时效率和灵活性二者也是直观的，并且所述协同例程接口被适用于以给出最终用户很大灵活性的容易使用的方式来提供用户定制的SIP和SDP修改，同时保护系统免于受到将由紧密耦合的协同例程接口造成的不期望的负面影响。

Description

用于定制SIP和SDP协议的用户协同例程接口

相关申请

本申请要求2007年8月8日提交的美国临时申请No.60/964,027的权益。v技术领域

本发明涉及电信系统。更特别地，本发明涉及协同例程(co-routine)在电信系统中的使用。

背景技术

当今的电信系统继续以非常迅速的步调在范围和复杂性上增长。促成这一增长的因素之一是低成本存储器和处理功率的可用性，其接着又促进了新一代电信协议(例如SIP(会话发起协议(SessionInitiation Protocol))和SDP(会话描述协议))的开发。这些面向未来的协议是基于ASCII(美国信息交换标准码)的、可扩展的并且与早期协议(其中运行时的机器效率的估价高于程序员生产率)相比具有更高的人类可读性。

这些新的协议与较旧的协议相比携带了关于它们所支持的电信服务的更多信息，并且在使系统适应(tailor)特定应用的许多灵活性来源于以非常特定的方式修改协议消息中的数据的能力。因为诸如SIP和SDP的协议是基于ASCII的，所以数据有助于它们被最终用户修改，尤其是被负责网络工程和计划的技术人员修改。在过去，“复杂的基于二进制的”协议的使用将需要制造商的工程设计来实现这样的定制。

一些电信系统传统地结合了用于特殊应用的可选的集成BASIC(初学者通用符号指令码)解释器(interpreter)。作为系统中独立运行的调度进程(scheduled process)，BASIC程序将发送且接收来自系统内CTI(计算机电话接口)元件的进程间消息以控制用于专门应用的呼叫处理(call processing)，否则这些专门应用可能需要使用外部主计算机。还从BASIC向一些OS(操作系统)控制提供了访问，其允许制造商实现对已发布软件的程序错误修正(bug fix)。这些制造商提供的BASIC程序将减轻一些类型的程序错误的故障现象，直到新的软件包被发布来校正该问题。

因为BASIC是容易使用的尤其非常适合处理ASCII字符串的更高级语言，所以自然考虑最终用户技术人员或者制造商会用其实现SIP和SDP消息数据的定制修改。有用修改的实例将是根据日时来改变SDP“供应(offer)”内的数据以便在高业务(traffic)时段期间减小网络加载。这会起作用，因为SDP协议携带与由媒体会话所需的比特率有关的信息。

见图1，BASIC进程10和其他系统进程20之间的交互方法是一种在其中BASIC是由系统调度器(scheduler)5调度的独立运行进程并且发送和接收到系统的其它元件的进程间消息(IPM)30的方法。当将这样的方法应用于诸如电信协议处理这样的应用时，所述方法是不灵活的并且效率低的。需要将信息发送到BASIC进程10的任何实时系统软件20必须向其发送IPM 30并且然后等待响应，同时仍接收其它实时事件输入。

需要等待响应并且同时仍接受其它事件输入是由电信系统必须实时处理数据的事实而造成的，并且在BASIC被作为独立调度的进程而运行的情况下来自BASIC的响应将被严重延迟。更简明的接口允许将BASIC作为在期望其处理的精确点处直接插入(in-line)的简单函数调用而被调用(invoke)。这还将避免与调度和I PM相关联的处理开销。

发明内容

本发明结合使用协同例程(co-routine)来实现BASIC程序和其中要修改(例如)SIP和SDP数据的系统中的点之间的类似函数的接口的方法。从最终用户的观点来看该协同例程接口是直观的，并且从系统设计者的观点来看实时效率和灵活性二者也是直观的。

本发明的方法应用其协同例程接口以便以给出最终用户很大灵活性的容易使用的方式来提供用户定制的SIP和SDP修改，同时保护系统免于受到将由紧密耦合的协同例程接口造成的不期望的负面影响。

附图说明

图1示出在BASIC进程和计算机系统中的另一个进程之间进行通信的传统方法。

图2示出传统的子例程调用机制的处理图。

图3示出协同例程调用机制的处理图。

图4示出本发明的上下文管理处理的流程图。

图5示出本发明的回调(callback)方法的处理图。

具体实现方式

协同例程

通常以分层的方式来完成函数调用(图2)。在层次顶部处的例程“A”41调用该层次中较低的例程“B”42以执行某一动作。当“B”已完成时，其返回到在“A”中“B”被调用的点处的“A”。之后，“A”可以再次调用“B”。此外，“B”可以调用该层次中甚至更低的例程“C”43，但是最终调用的每个较低的例程完成其函数并且返回到该层次中其更高的调用方。

协同例程是本领域公知的图2的子例程机制的一般化。见DonaldKnuth的Fundamental Algorithms第三版。Addison Wesley的1997.ISBN 0-201-89683-4.Section 1.4.2：Coroutines，pp.193-200以及在计算机科学文献中的许多其它参考。与子例程相反，协同例程是函数调用的特殊形式，在其中两个例程“A”和“B”以完全对称的方式彼此调用(图3)。从“A”51到“B”52的调用从“B”中的点恢复“B”(在该点处其最后调用“A”)。然后，当“B”调用“A”时，“A”从“A”中的点恢复(在该点处其最后调用“B”)。这些特殊形式的函数调用通常被称为“转移(yield)”而不是“调用”，其中“A”转移“B”并且反之亦然。

在本发明中，图3中例程“A”51和“B”52的角色分别由电信系统的呼叫处理软件和BASIC程序扮演。可以从图3中看到，在例程“A”和例程“B”之间确实存在非常紧密的关系。

传统上，通常在诸如用于Macintosh^TM计算机的Apple的最初操作系统(OS)之类的“协同操作多任务处理(co-operative multitasking)”系统中，协同例程概念具有有些受限的应用。在这些类型的应用中，由系统程序员提供例程“A”和例程“B”二者是惯例，这再次归因于例程之间高度交互且紧密的关系。相反，本发明结合一种方法，通过该方法电信系统的制造商提供作为产品的集成(integral)部分的例程“A”，但是有可能由负责网络工程和计划的客户的技术人员单独地并且在随后编写例程“B”(BASIC程序)。该BASIC程序然后被加载并且以与任何其它BASIC程序相同的方式运行，而且变成经由本发明的协同例程接口耦合到系统以便提供之前描述的适应服务。

本发明的一个目的是教导一种方法，通过该方法实现将两个不同的编程环境耦合成一个工作协同例程关系。

从用户的观点来看，通常由BASIC解释器提供的编程环境是高度交互的，尤其在程序开发阶段期间。用户(在这种情况下是程序员)可以输入程序语句、执行整个程序或其较小的程序段、检查中间结果、进行校正以及再试一次。最后，得到推测完全没有程序错误的BASIC程序。在所有该过程期间，存在程序员和BASIC之间的持续相互影响。程序员在终端上输入数据；BASIC以终端输出以及可能的错误消息回复。

但是当BASIC程序采取上述协同例程接口中的例程“B”的角色时，其一定不被允许提示终端输入、发布错误消息并且等待用户响应或者执行将停止其执行的任何函数。当在实时环境中作为来自系统软件的协同例程而被调用时，BASIC程序必须基本上被限制成纯计算。例如，如果BASIC程序包括INPUT语句并且作为来自实时系统进程的协同例程而被执行，则实时进程将在其等待终端输入的点处停止执行以满足INPUT语句。负责以即时方式处理事件的实时进程的执行的停止将导致系统故障。

因此，本发明的另一个目的是教导一种方法，通过该方法可以在BASIC程序用作协同例程时改变该BASIC程序的环境以便防止这些危险的负面影响。

BASIC解释器

在优选实施例中，将BASIC解释器假设为在其中编写例程“B”的编程环境，而不是在其中执行例程“B”的环境。最终，例程“A”和例程“B”二者以运行在处理器上的机器代码的形式来操作。例程“A”可以已以C编程语言或另一种编译的编程语言编写，并且然后被编译和链接以变成由制造商提供的电信系统软件的一部分。类似地，BASIC解释器自身可以以C或另一种编译语言编写。在这两种情况下，为了速度和效率，例程“A”的部分和BASIC解释器优选地结合以汇编语言编写的部分，因为汇编语言几乎直接被翻译成机器语言。有必要以高的层次来简单地描述BASIC解释器如何处理用户的BASIC程序。本领域技术人员已公知在编译器和解释器背后的详细概念，并且将不在本文中叙述。

与编译器相反，BASIC解释器不会将用户的BASIC程序转换成机器语言并且然后在以后执行该机器代码。而是作为代替，BASIC解释器读取用户的BASIC程序作为其数据，并且渐进地执行由该数据调用的动作。BASIC解释器将优选地采取措施来通过内部表示处于经组织以便流线(streamline)执行的简略形式(abbreviated form)的用户的BASIC程序来最小化处理器开销。但是用户的BASIC程序仅用于使得BASIC解释器选择并且执行已经在该BASIC解释器内提供的适当的机器代码的序列。例如，当遇到表达式″x+Y″时，解释器执行机器代码以进行被分配给符号x和Y的值的相加。当遇到“PRINT”语句时，解释器执行机器代码以便将在打印语句中指定的数据输出到终端。本文的要点是从协同例程接口的观点来看，例程“A”和“B”仅是普通的机器代码。

在描述本发明中，更方便的是首先从BASIC程序的编写器(writer)(“B编写器”)的观点来描述操作，之后从系统代码的编写器(“A编写器”)的观点来描述操作。这些描述之后，将描述操作的详细方法。在下面的描述中，术语“上下文(context)”指在进程执行时有效的程序环境(处理器状态、机器寄存器等等)。在图3中，例程“A”具有在其中其进行执行的上下文，并且例程“B”具有其中其进行执行的另一个上下文。本领域技术人员已公知必须在任何例程可以执行之前建立上下文。

从B编写器的观点来看的操作

在优选实施例中，通过执行BASIC程序内的特殊函数调用YIELD_TO_SYSTEM(context)，BASIC程序变得被注册为由其它系统组件使用的协同例程，其中“context”指的是在调用点处BASIC程序的执行期间有效的程序环境。这里是示范用于传递自变量(argument)的该函数和系统变量的使用的实例BASIC程序。该程序与随后给出的“C”程序一起工作。

10    NEWLINE$＝CHR$(10)

20    DETACH()

30    REPEAT

40        YIELD TO SYSTEM(1)

50        HOUR$＝LEFT(TIME$，2)

60        WO_ARG_1＝0

70        IF HOUR$＞＝″08″AND HOUR$<″17″

80            SDP$＝RW_ARG_1$

90            POSl＝INSTR(1，SDP$，″m＝audio″)

100           IF POSl

110              POS2＝INSTR(POS1，SDP$，″RTP/AVP″)

120              IF POS2

130                POS3＝INSTR(POS2，SDP$，″0″)

140                IFPOS3＝0THEN POS3＝INSTR(POS2，SDP$，″0″+NEWLINE$)

150                IF POS3

160                   SDP$＝LEFT(SDP$，POS3-1)+EIGHT(SDP$，POS3+2)

170                   WO_ARG_1＝1

180                ENDIF

190                POS3＝INSTR(POS2，SDP$，″8″)

200                IF POS3＝0THEN POS3＝INSTR(POS2，SDP$，″8″+NEWLINE$)

210                IF POS3

220                   SDP$＝LEFT(sDP$，POS3-1)+RIGHT(SDP$，POS3+2)

230                   WO_ARG_1＝1

240                ENDIF

250                RW_ARG_1$＝SDP$

260              ENDIF

270          ENDIF

280       ENDIF

290    UNTIL 0

随后将给出该程序的逐行解释。这里，将仅给出概述来覆盖最重要的概念。

在行20处的语句分离(detach)BASIC程序以释放从其运行该BASIC程序的终端。如果这没有进行，则随后在BASIC程序变成被注册为协同例程时该终端将被使得(render)不可使用。直到执行YIELD_TO_SYSTEM(1)语句，BAS I C程序可以执行可能被期望的任何类型的计算。

当在行40处的YIELD_TO_SYSTEM(1)第一次被调用时，不存在要转移到的先前上下文，所以执行协同例程初始化。当前的BASIC程序上下文被保存为上下文1(YIELD_TO_SYSTEM0的自变量)，然后根据本发明来完成对该上下文的某些修改，以便在随后转移BASIC以作为协同例程时防止出现不期望的或危险的负面影响。如之前所描述的那样，需要这些修改，因为当转移BASIC程序以在随后作为来自另一个系统进程(图3中的例程“A”)的协同例程时，该BASIC程序实际上仍作为该进程的一部分而执行，而不是作为BASIC来执行。

根据本发明完成的修改是：

·来自PRINT语句或错误消息的任何和所有终端输出都被忽略并且不会出现。

·读取来自INPUT语句的终端输入的任何尝试或作为已经返回到BASIC的提示(prompt)的结果，导致从BASIC的立即退出并且控制转移回到调用系统进程。

·(在优选实施例中被用来终止BASIC程序的)BYE语句的执行导致从BASIC的立即退出并且控制转移回到调用系统进程。

·可能具有不期望的负面影响的任何其它特殊面向应用的函数被禁用并且在被执行的情况下将导致可截获的错误。

此外，这些上下文修改的目的是防止将调用作为协同例程的BASIC的系统进程在处于BASIC协同例程的时候或者等待资源或者执行不期望的动作。假设该协同例程执行“纯计算”。

注意，在执行第一个YIELD_TO_SYSTEM0之前，BASIC自由地进行它正常会做的任何动作；限制其对系统的访问的上下文修改仅在第一次执行YIELD_TO_SYSTEM0之后起作用。

在该初始化进程已完成之后，BASIC将标记设置成向任何潜在用户(例程“A”)指示协同例程上下文1(在该实例中)可以供使用。在协同例程接口已被初始化之后，BASIC进程进入休眠状态直到其接收到信号，所述信号或者是当BASIC程序作为协同例程执行时在该BASIC程序内出现的严重错误或者是已明确地请求该程序退出。在优选实施例中，该信号是操作系统事件，但是可以使用任何适合的信令手段(signaling means)。BASIC进程必须进入该休眠状态来防止在其被转移为协同例程之前对其保存的上下文的任何后续修改。

因此，当系统软件随后通过协同例程接口转移到BASIC时，BASIC程序的上下文将正好是当YIELD TO SYSTEM(1)语句被第一次执行时它所处的上下文，并且BASIC程序将无缝地从该点起恢复执行作为协同例程。对于系统的其余部分(尤其是系统调度器)，转移到作为协同例程的BASIC的系统软件简单地执行其自己进程内的函数调用，并且最初的BASIC进程仍然处于休眠状态。这是本发明的关键概念。

当系统软件(例程“A”)转移到BASIC协同例程时，BASIC程序将看来像从行40处的YIELD_TO_SYSTEM0函数调用“return(返回)”。然后该程序可以访问如下所描述的根据“passing arguments(传递自变量)”传递给其的任何自变量，并且执行任何期望的计算。然后将返回结果。典型地，然后程序将循环回(loop back)到相同的YIELD_TO_SYSTEM0函数调用，但是这不是必需的。这是该实例中所发生的状况，因为在行30处的“REPEAT”语句和在行290处的“UNTIL 0”语句构成无限循环结构。一旦该YIELD_TO_SYSTEM0函数调用被再次执行，在该点(例程“B”)处的BASIC的上下文就被保存并且控制在先前已被转移到BASIC的点处被转移回到系统软件(例程“A”)。再次，这在图3中示出。

本领域普通技术人员将会认识到实际上存在可以被编写以代替上述一个程序的无限数目的可能BASIC程序。该实例仅意味着示范所涉及的原理并且不应该以限制的方式理解。

传递自变量

为了使BASIC程序执行一些有用的数据处理，显然必须存在从例程“A”到例程“B”来回传递自变量的机制。这可以通过指定共享的存储区来完成，在所述共享的存储区中限定一些变量。例程“A”可以将适当的值存储在变量中，并且例程“B”可以检索它们。类似地，例程“B”可以将结果存储在变量中，并且例程“A”可以检索那些结果。在优选实施例中，BASIC解释器支持只读变量、只写变量以及读写变量的概念。按照惯例，例程“A”将特定于应用的值存储到“B编写器”可以用作输入的某些变量中。使用用于传递输入并且返回结果的相同读写变量具有下面的优点，如果不需要对输入的变化，则自动返回正确的未变化的值。

上面BASIC程序的详细描述

现在详细地描述上面给出的实例BASIC程序。尽管该程序例证了由本发明教导的能力的特定使用，但是本领域普通技术人员将会想到由通过该协同例程接口调用的BASIC程序的数据操作的许多其它实例。因此，该实例不应该理解为限制的方式。

在行10处，程序将变量NEWLINE$设置成包含换行字符(ASCII20)的字符串。这将在以后使用。在行20处，程序调用函数来从其被发起的终端分离该程序，以防止在程序随后变成被注册为协同例程时该终端被使得不可使用。行30限定从行30向下延伸到行290的无限循环结构。行40使得BASIC执行之前详细描述的上下文修改(仅第一次)，并且然后转移回到系统并等待来自系统的作为协同例程的后续调用。当系统需要调用BASIC程序时，它将建立某些输入参数，并且然后转移回到BASIC。这将使得BASIC程序恢复行50处的执行。

这时候，重新陈述该实例BASIC程序的目的是有用的。系统管理员希望处理用于在高业务时段期间(例如在从08:00到16:59的时间段期间)完成的调用的SDP供应，以使得这些调用需要较少的网络资源。具体来说，管理员希望改变在SDP供应内的数据来删除在从08:00到16:59的小时期间呈现在SDP中的某些编解码器(编码器/解码器)选择。这相当于在用于在该时间段期间完成的调用的数据中的所需位置处从SDP数据删除“0”和/或“8”。

在行50处，BASIC程序调用函数LEFT(TIME$，2)。变量TIME$是以字符串(例如“09:23:50”)返回当前壁时间(wall time)的系统变量。LEFT函数提取该字符串的左边两个字符作为HOUR$变量。在行60处，系统变量WO_ARG_1被设置成零。按照惯例该变量是从BASIC传递回到系统的返回值之一。将其设置成0指示程序没有执行SDP操作。如果随后没有被设置成非零值，则这将被作为状态响应返回给系统。在行70处，进行检查以确定当前壁时间是否在08:00到16:59之间，在这些小时期间将发生SDP操作。如果不在所需的时间段内，则语句将评估为false(假)结果并且控制将向下跳到行280，并且从那里到行290。在行290处的UNTIL 0语句将一直评估为false条件(0被认为是false)，所以控制将返回到行30，并且然后到行40，在行40处BASIC将再次转移回到系统。因为没有发生SDP操作，所以该调用将以最初的SDP供应进行。

然而，如果在行70处，当前壁时间处于08:00到16:59的时间段内，则IF语句将评估为true(真)结果并且控制将被传递到行80。在行80处，变量SDP$被设置成RW_ARG_1$。当协同例程被调用时，按照惯例，变量RW_ARG_1$是由系统传递到BASIC的输入自变量之一。它表示最初的SDP供应数据。作为读写变量，它可以被BASIC程序改变并且作为结果返回到系统，并且在这种情况下这确切地是将会发生的。如果被打印到终端，存储在行80处的SDP$变量中的数据将以下面的形式出现：

v＝0

o＝root  12705837001270583700 IN IP4192.168.42.59

s＝call

c＝IN IP4 192.168.42.59

t＝00

m＝audio58520RTP/AVP  0 8 9 2 3 18 4 101

a＝rtpmap：0pcmu/8000

a＝rtpmap：8pcma/8000

a＝rtpmap：9g722/8000

a＝rtpmap：2g726-32/8000

a＝rtpmap：3gsm/8000

a＝rtpmap：18g729/8000

a＝rtpmap：4g723/8000

a＝rtpmap：101telephone-event/8000

a＝fmtp：1010-16

a＝ptime：20

a＝sendrecv

上面每一行都以ASCII 10(换行)字符结束。在行90处，INSTR函数搜索字符串以寻找文本“m＝audio”，并且将POS1设置成在找到其的字符串内的字符位置。行100检查INSTR找到字符串(如果没有找到字符串则INSTR返回0)。如果在SDP中没有找到“m＝audio”，则POS1将是零并且控制将向下跳到行270并且像以前那样最终返回到行40。然而，如果找到字符串“m＝audio”，则我们移动到行110并且试图在SDP供应中找到字符串“RTP/AVP”。再次，如果这没有被发现，则POS2将是零并且在行120处我们跳到行260且然后返回行40。但是如果找到“RTP/AVP”，则我们进入行130，在行130处我们寻找字符串“0”。在上面示出的实例SDP中，这将被发现为粗体的“0”。因为SDP的规则允许该值出现，甚至在行的结束处(在该实例中在此处放置值“101”)，我们还必须检查后面有换行字符(其终止SDP供应的每一行)的“0”。这在行140处被检查。行150检查是否我们通过任一方法找到了“0”，如果是那样的话，行160通过将一直到仅在“0”之前的最初的SDP的左边部分(LEFT函数)与仅超出“0”而开始的最初的SDP的右边部分(RIGHT函数)级联(concatenate)来创建新的SDP供应文本。这具有从SDP供应中删除“0”的效果。类似地，从行190到240从SDP供应中删除了“8”。在这两种情况下，行170和230将返回状态系统变量设置成1以向该系统指示SDP操作是成功的。最后，在行250处，将新的SDP供应存储回到要被传递回该系统的读写变量RW_ARG_1$中。然后控制再次返回到行40处，并且BASIC转移回到系统。系统软件(例程“A”)现在将以可能已被BASIC程序(例程“B”)修改的SDP供应来进行。

多个协同例程上下文

上面的实例使用YIELD_TO_SYSTEM(1)。可以存在多于一个的活动的(active)协同例程上下文。如果例如按照惯例系统软件被编码以使用上下文1来用于SDP数据修改，则将这作为协同例程而处理的BASIC程序将使用YIELD_TO_SYSTEM(1)。可能存在被编码以使用上下文2的另一个独立的进程(例如SIP修改或调试器)。将YIELD_To_SYSTEM(2)用于这些服务的另一个BASIC程序将运行。

从“A编写器”的观点来看的操作

我们将假设“A编写器”以C编程语言编写系统软件(例程“A”)，其然后被编译且链接以变成由制造商提供的电信系统软件的一部分，如之前所提到的那样。在该代码中适于调用BASIC协同例程(例程“B”)的点处，如下面所给出的代码片段中示出的那样采取一些步骤，但是该进程实际上仅仅是简明的函数调用：

char sdp_data[MAX_SDP_DATA_STRING_LENGTH]；

/*codeto set up sdp datastring*/

/*

*The context index is set to 1 to agree with the YIELD_TO_SYSTEM(1)

*statement in the BASIC program.

*/

context_index＝1；

/*

*First besurethat the co-routine interface is initea.

*/

if(bas_coroutine_data[context_index].bas_context{

    bas_coroutine_data[context_index].rw.str_arg.ptr ＝sdp_data；

    bas_coroutine_data[context_index].rw.str_arg.max_len＝

MAX_SDP_DATA_STRING_LENGTH ；

    bas_coroutine_data[context_index].wo.int_arg＝TRUE；/*in

case BASIC does not set it*/

/*Must set job.context toa non-zerovalue to indicate that we

are not initing.*/

    bas_coroutine_data[context_index].job_context＝1；

    bas_context_swap(&bas_coroutine_data[context_index].job_context，

&bas_coroutine_data[context_index].bas_context)；

    if(bas_coroutine_data[context_index].wo.int_arg＝＝1){{

        /*BASIC program was successful*/

    }else{

        /*BASIC program was unsuccessful*/

    }

}

/*codetousepossibly modified sdp data string*/

上面“C”代码片段的详细描述

上面的代码片段是非常简明的。第一个“if”语句检查数据结构变量以了解该上下文是否是可用的。如果BASIC程序还没有运行并且也没有执行其YIELD_TO_SYSTEM0函数，则该变量将仍然是零，并且将不对BASIC程序进行调用。如果BASIC程序已初始化了协同例程接口，则该变量将不是零，并且将执行“if”的主体。

“context_index(上下文索引)”被设置成1以与在从BASIC进行的YIELD_TO_SYSTEM0函数调用中使用的自变量一致。可以存在运行的另一个BASIC协同例程，以及使用其的另一个“C”程序，并且按照惯例应该同意该第二对程序使用不同的“context index”值(例如2)。

下一个语句建立BASIC程序要修改的SDP字符串(″sdp_data″)的指针的输入自变量″rw.str_arg″。因为这是BASIC的读写变量，所以设置″max_len″变量来向BASIC指示当存储在该字符串中时有多少存储器是可用的。这防止BASIC编写得超出为该字符串分配的存储器。下一个语句初始化返回状态值，以使得在BASIC程序因为某些原因而没有设置该值时，它将默认为TRUE。

″job_context″变量然后被设置成任何非零值(在该实例中为“1”)。(当将要进行协同例程初始化时)这向正要被调用的bas_context_swap0函数指示我们不是第一次调用其，而是我们仅希望用已经运行的BASIC协同例程来执行上下文交换(swap)。(当BASIC程序执行其YIELD_TO_SYSTEM()函数调用，bas_context_swap()也被调用时，″job_context″变量第一次为零，所以如之前讨论的那样执行协同例程初始化。)

现在调用bas_context_swap()函数，这执行上下文交换，其在最后执行的YIELD_TO_SYSTEM()语句之后的语句处转移到BASIC。BASIC取(fetch)自变量、进行其处理，并且将其结果存储在系统变量中。

当BASIC程序执行相同或另一个YIELD_TO_SYSTEM()语句时，控制被转移回到该C语言代码片段，并且返回对bas_context_swap()的调用。该C代码片段然后可以从该系统变量获得任何结果。下一个“if”语句检查按照惯例被用来指示BASIC程序在其工作中是否成功的这些变量(″wo.int_arg″)中的一个。有可能被BASIC程序修改的变量″sdp_data″现在可用于C代码片段的另一个用户。

BASIC和“C”协同例程自变量之间的对应

下面的表示出实例C代码片段和实例BASIC程序中的结构元素之间的关系。

C结构元素	BASIC系统变量	注解
			bas_coroutine_data[i].rw.str_arg.ptr	RW_ARG_1$	1
bas_coroutine_data[i].wo.int_arg	WO_ARG_1	2

注释：

1)该字符串变量自变量可以由任一个作业(job)读取或编写。

2)该整数自变量可以仅由BASIC编写。

执行内容交换

我们已讨论了协同例程原理、初始化接口时要采取的步骤和运行在协同例程关系中的BASIC程序和C代码片段的特定实例。我们现在描述执行协同例程上下文交换、传递C和BASIC协同例程之间的控制的实际例程。这是当BASIC调用YIELD_TO_SYSTEM()函数时或者当C代码片段调用bas_context_swap()函数时被调用的公共代码。

因为该代码必须保存包括机器寄存器的整个程序上下文，并且保持程序的堆栈(以后进先出的方式访问的并且不能直接由更高等级的语言访问的存储区)，所以该代码通常必须以机器语言编写。为了更好地解释上下文变换代码，将在图4中给出流程图，之后解释该流程图。

如所提到的那样，当YIELD_TO_SYSTEM0函数被调用时从BASIC调用该公共代码，并且当bas_context_swap()函数被调用时从C代码片段调用该公共代码。第一次调用该代码是在BASIC进程中运行的BASIC程序第一次调用YIELD_TO_SYSTEM()的时候。见图4。处理在101处开始。在102处，所需要的所有作业上下文信息被存储在当前作业的(BASIC的)堆栈上。如上面所提到的那样，该堆栈包含已在当前作业(BASIC)的正常操作期间存储的许多作业上下文项，但是该附加的信息包括机器寄存器以及通常不被存储的其它信息。整个地，该信息包含随后恢复该程序所需的所有信息。在103处，进行检查来看这是否是该代码第一次被调用。这将是第一次，所以我们在104处继续。在步骤104处，刚刚保存的BASIC程序的环境被改变以防止如之前所提到的那样在随后将BASIC程序作为协同例程而调用时的危险负面影响。随后将更详细地解释该进程。在105处，为BASIC程序建立新的堆栈区域以使得它可以在不以任何方法扰乱所保存的上下文的情况下安全地在106处进入休眠状态。这是重要的，因为所保存的上下文将在随后被恢复，并且如果所恢复的上下文不是确切相同的则将不可能进行作为协同例程的正确操作。最初BASIC进程现在处于休眠状态并且决不会从该点推进。

现在，C代码片段通过执行bas_context_swap()函数来调用该代码。

我们再次在101处开始。尽管我们将执行确切相同的代码，但是该调用来自包含C代码片段的系统进程，而不是来自于BASIC进程。在102处，所需的所有作业上下文信息被存储到当前作业的堆栈上，但是这次它将是包含C代码片段的系统进程的上下文和堆栈。在103处，检查将确定这不是第一次被调用，所以我们将在107处继续。指向当前上下文的指针被作为FROM指针(意味着我们正要离开的上下文)而存储在BASIC和C代码片段都可以访问的存储区中。在108处，指向之前被保存的上下文的指针被作为TO指针(意味着我们正要进入的上下文)而被取得。在109处，恢复之前的上下文。这将是在BASIC早先调用该代码时被保存的上下文。在110处，该代码将返回。正常的分层函数将返回到调用其的程序，如图2中所示。然而，上下文交换导致该代码如图3所示的那样充当协同例程。因此，在110处，控制被返回到其上下文早先被保存的BASIC协同例程。该代码从C调用，但是返回到BASIC。

现在运行BASIC程序，并且在某一点它将调用YIELD_TO_SYSTEM()函数。该代码将在101处被再次调用。在102处将再次保存当前上下文(这次是BASIC上下文)，并且在103处控制将被再次传递到107(存储当前上下文指针)，并且所保存的C代码片段的上下文将在108和109处被恢复。在110处，我们将返回，并且再次不返回到调用方，而是如图3中那样返回到C代码片段。这次该代码将从BASIC调用但是返回到C。实际上，在图3中，链接左边例程“A”和右边例程“B”的实箭头55仅仅是对该上下文交换代码的调用，其中C代码片段扮演例程“A”的角色而BASIC程序扮演例程“B”的角色。

改变BASIC程序的环境

之前提到本发明的另一个目的是教导一种方法，通过该方法可以在BASIC程序被用作协同例程时改变该BASIC程序的环境以防止危险的负面影响。该环境相当于BASIC解释器调用以执行输入/输出并且访问系统资源的函数集。在优选实施例中，对所有这些函数的访问是间接的，使用公知的“回调函数”。当BASIC解释器被第一次调用时，它传递BASIC用来输入/输出并且访问系统资源的函数的地址列表(图5中的“回调函数地址列表”62)。BASIC然后通过从该列表获得所需函数的地址以及然后调用其来以间接的方式来调用这些函数(图5)。可替换方式可以是简单地以如图2中所示的正常方式来直接调用该函数。

使用回调函数的一个优点是平台独立性，因为BASIC解释器没有与输入/输出的细节以及平台的系统接口需求联系到一起，并且由此可以保留专用地处理BASIC语言本身的“纯代码”。但是在本发明中，回调函数的使用还提供了当BASIC程序作为协同例程运行时用于改变该BASIC程序的环境的非常灵活且有效的手段。当第一次访问该协同例程并且YIELD_TO_SYSTEM()被第一次调用时，图4中的上下文交换代码104修改该回调函数列表，从而在作为协同例程而执行时用新的函数地址代替那些被认为危险的函数地址。这是一种灵活的方法，因为仅需要代替特定的函数。而且还是有效的，因为一个地址的代替自动覆盖了BASIC内对该函数的所有调用。例如，在图5中，如果在63中的最初函数“A”是处理终端输入的函数，并且希望在处于协同例程时禁用该函数，然后可以改变62中的条目“A的地址”以使得它包含不执行终端输入但是可能报告错误的另一个函数的地址64。一旦执行该代替，来自BASIC解释器的所有“对A的函数调用”(图5中示出存在两个对函数“A”的调用)将自动使用新的函数(“用于函数A的替换代码”)开始。

如果没有使用代替回调函数的该方法，则在进行潜在危险的函数调用的BASIC解释器内的每个点处，将必须存在代码来检查在该点处(最初的或新的)将调用哪个函数。这样的检查将招致在实时系统中不可接受的运行时间的处理器开销，并且将倾向于产生错误，因为每次出现的函数调用都将必须被单独地处理。回调地址的代替仅需要在协同例程接口被第一次初始化时进行一次。

Claims (15)

1.一种用于使用非实时软件组件来管理由实时计算机系统中的实时程序使用的数据的设备，其中实时程序在其正常执行期间不能被停止、暂停或挂起，并且其中非实时程序在其正常执行期间能够在任意点处被停止、暂停或挂起，所述设备包括：

一个或多个实时程序，每一个还包括一个或多个实时组件和子组件；

一个或多个非实时程序，每一个还包括一个或多个非实时数据管理组件和子组件，以及一个或多个实时组件和子组件；

不能够用作实时程序的子组件的每一个非实时数据管理软件组件的敏感非实时子组件；

实时环境保护子组件，以用用作实时程序的子组件的实时子组件来代替每个敏感非实时子组件；

实时计算机系统的上下文交换软件组件，以在实时软件组件和非实时软件组件之间切换上下文；

非实时程序的非实时数据管理软件组件，以管理由实时程序使用的数据；

用于根据将由实时软件组件使用的非实时数据管理软件组件产生第一数据集的装置；

用于使用所述实时环境保护子组件来用实时子组件代替所述非实时数据管理软件组件的每个敏感非实时子组件的装置，从而将所述非实时数据管理软件组件转换成实时数据管理软件组件；

用于存储所述第一数据集的装置，所述第一数据集待由要被所述实时软件组件使用的上下文中的所述实时软件组件使用；

用于使用所述实时计算机系统的上下文交换软件组件来在实时软件组件和非实时软件组件之间切换上下文的装置，从而将要由所述实时软件组件使用的所述第一数据集传递到所述实时软件组件；

用于使用所述实时软件组件来检索所述第一数据集并且产生要由所述非实时软件组件使用的第二数据集的装置；

用于存储所述第二数据集的装置，所述第二数据集待由要被所述非实时软件组件使用的上下文中的所述非实时软件组件使用；以及

用于使用所述实时计算机系统的上下文交换软件组件来在实时软件组件和非实时软件组件之间切换上下文的装置，从而将要由所述非实时软件组件使用的所述第二数据集传递到所述非实时软件组件；以及

用于使用所述非实时软件组件来处理所述第二数据集的装置。

2.根据权利要求1所述的设备，还包括：

实时环境恢复子组件，以将非实时软件组件的每个实时环境保护子组件恢复成最初的敏感非实时子组件；

用于使用所述实时环境恢复子组件来将非实时软件组件的每个实时环境保护子组件恢复成所述最初的敏感非实时子组件的装置；以及

用于使用所述非实时数据管理软件组件来检索并处理由所述实时软件组件产生的所述第二数据集的装置。

3.根据权利要求1所述的设备，其中以解译语言编写多个所述一个或多个非实时程序并且在解译语言环境中执行该多个所述一个或多个非实时程序。

4.根据权利要求3所述的设备，其中所述解译语言及解译语言环境从由以下各项组成的组中选择：

BASIC语言及其解释器；

Python语言及其解释器；

Ruby语言及其解释器：

Java语言及其解释器；以及

JavaScript语言及其解释器。

5.根据权利要求1所述的设备，其中使用编译语言编写多个所述一个或多个实时程序并且在编译语言环境中执行该多个所述一个或多个实时程序。

6.根据权利要求5所述的设备，其中所述解释语言及其环境从由以下各项组成的组中选择：

C语言及其编译器；

C++语言及其编译器；以及

C#语言及其编译器。

7.根据权利要求1所述的设备，其中使用与计算机系统有关的汇编语言编写多个所述一个或多个实时程序并且在汇编语言环境中执行该多个所述一个或多个实时程序。

8.根据权利要求1所述的设备，其中所述实时环境保护子组件使用回调表来用实时子组件代替所述非实时数据管理软件组件的每个敏感非实时子组件。

9.根据权利要求1所述的设备，其中用于使用所述实时环境保护子组件来用实时子组件代替所述非实时数据管理软件组件的每个敏感非实时子组件的装置包括回调表。

10.根据权利要求1所述的设备，其中用于根据非实时数据管理软件组件来产生第一数据集的装置包括解译语言及解译语言环境。

11.根据权利要求1所述的设备，其中用于根据非实时数据管理软件组件来产生第二数据集的装置包括编译语言及编译语言环境。

12.根据权利要求1所述的设备，其中用于根据非实时数据管理软件组件来产生第二数据集的装置包括与计算机系统有关的汇编语言及汇编语言环境。

13.根据权利要求1所述的设备，其中用于使用所述非实时数据管理软件组件来检索并处理由所述实时软件组件产生的所述第二数据集的装置包括解译语言及解译语言环境。

14.一种用于使用非实时软件组件来管理由实时计算机系统中的实时程序使用的数据的方法，其中实时程序在其正常执行期间不能被停止、暂停或挂起，并且其中非实时程序在其正常执行期间能够在任意点处被停止、暂停或挂起，所述方法包括下述步骤：

识别不能被用作实时程序的子组件的每个非实时数据管理软件组件的敏感非实时子组件；

使用回调表来实现实时环境保护子组件以用用作实时程序的子组件的实时子组件来代替每个敏感非实时子组件；

实现所述实时计算机系统的上下文交换软件组件来在实时软件组件和非实时软件组件之间切换上下文；

实现非实时数据管理软件组件来管理由实时程序使用的数据；

执行非实时数据管理软件组件来产生由实时软件组件使用的第一数据集；

执行所述实时环境保护子组件以经由回调表来用实时子组件代替所述非实时数据管理软件组件的每个敏感非实时子组件，从而将所述非实时数据管理软件组件转换成实时数据管理软件组件；

存储第一数据集，该第一数据集待由要被所述实时软件组件使用的上下文中的所述实时软件组件使用；

执行所述实时计算机系统的上下文交换软件组件来在实时软件组件和非实时软件组件之间切换上下文，从而将由所述实时软件组件使用的所述第一数据集传递到所述实时软件组件；

执行所述实时软件组件来检索所述第一数据集并且产生待由所述非实时软件组件使用的第二数据集；

存储第二数据集，该第二数据集待由要被所述非实时软件组件使用的上下文中的所述非实时软件组件使用；

执行所述实时计算机系统的上下文交换软件组件来在实时软件组件和非实时软件组件之间切换上下文，从而将待由所述非实时软件组件使用的所述第二数据集传递到所述非实时软件组件；以及

执行所述非实时软件组件以处理所述第二数据集。

15.根据权利要求14所述的方法，还包括以下步骤：

实现实时环境恢复子组件以将非实时软件组件的每个实时环境保护子组件恢复成最初的敏感非实时子组件；

执行所述实时环境恢复子组件来将非实时软件组件的每个实时环境保护子组件恢复成所述最初的敏感非实时子组件；以及

执行所述非实时数据管理软件组件来检索并处理由所述实时软件组件产生的所述第二数据集。

Images