Abstract: An apparatus includes: a first camera configured to view an environment outside a vehicle; a second camera configured to view a driver of the vehicle; and a processing unit configured to receive a first image from the first camera, and a second image from the second camera; wherein the processing unit is configured to determine first information indicating a risk of collision with the vehicle based at least partly on the first image; wherein the processing unit is configured to determine second information indicating a state of the driver based at least partly on the second image; and wherein the processing unit is configured to determine whether to provide a control signal for operating a device or not based on (1) the first information indicating the risk of collision with the vehicle, and (2) the second information indicating the state of the driver.

Abstract: An apparatus includes: a first camera configured to view an environment outside a vehicle; a second camera configured to view a driver of the vehicle; and a processing unit configured to receive a first image from the first camera, and a second image from the second camera; wherein the processing unit is configured to determine first information indicating a risk of collision with the vehicle based at least partly on the first image; wherein the processing unit is configured to determine second information indicating a state of the driver based at least partly on the second image; and wherein the processing unit is configured to determine whether to provide a control signal for operating a device or not based on (1) the first information indicating the risk of collision with the vehicle, and (2) the second information indicating the state of the driver.

Abstract: An apparatus includes: a first camera configured to view an environment outside a vehicle; a second camera configured to view a driver of the vehicle; and a processing unit configured to receive a first image from the first camera, and a second image from the second camera; wherein the processing unit is configured to determine first information indicating a risk of intersection violation based at least partly on the first image; wherein the processing unit is configured to determine second information indicating a state of the driver based at least partly on the second image; and wherein the processing unit is configured to determine whether to provide a control signal for operating a device or not based on (1) the first information indicating the intersection violation, and (2) the second information indicating the state of the driver.

Abstract: An apparatus includes: a first camera configured to view an environment outside a vehicle; and a processing unit configured to receive a first image from the first camera; wherein the processing unit is configured to determine a centerline of a road or a lane in which the vehicle is traveling; and wherein the processing unit is configured to determine a region of interest based on the centerline, the region of interest having a geometry that is based on a feature of the centerline.

Abstract: Techniques for identifying and organizing electronic messages are described. With some embodiments, a method receives a user interaction update from a messaging client associated with a first user. The user interaction update has data indicating that the first user interacted with an electronic message. The method may then determine that the first user is associated with a classification attribute that defines a relationship in a social network. Using the user interaction update, the a social classification rule corresponding to the classification attribute associated with the first user is then updated. The social classification rule may include data usable to organize a plurality of electronic messages. Finally, the method may optionally send the updated social classification rule to a messaging client associated with a second user, where the updated social classification rule can be used to organize electronic messages displayed by the messaging client associated with the second user.

Abstract: A mechanism for enabling session information to be shared across multiple processes in a multi-process environment is disclosed. There is provided a shared persistent memory-mapped file in a file system, which is mapped to the memory space of each of the processes. This file is used by all of the processes to store session information. Because the memory space of each process is mapped to the shared file, each process is able to access and manipulate all of the sessions in the system. Thus, sessions are no longer maintained on a process-specific basis. Rather, they are maintained on a centralized, shared basis. As a result, different requests pertaining to the same session may be serviced by different server processes without any adverse effects. Each process will be able to access and manipulate all of the state information pertaining to that session. By enabling session information to be shared, this mechanism eliminates the session management errors experienced by the prior art.

Abstract: An SLO (service level objective) is represented by a model that includes nodes that represent elements in a system that are used to fulfill the SLO and information that represents dependencies between the elements. Telemetry information is received describing a condition of an element in the system. The telemetry information can be applied to a particular procedure associated with a particular node in the model to determine if there is a problem associated with the element represented by the particular node. At least a portion of the telemetry information is applied to procedures to determine problem cause information describing which elements have problems relating to the SLO. A relative contribution of elements to a problem associated with the SLO is determined by analyzing the problem cause information and the dependencies between the elements.

Abstract: A mechanism for enabling session information to be shared across multiple processes in a multi-process environment is disclosed. There is provided a shared persistent memory-mapped file in a file system, which is mapped to the memory space of each of the processes. This file is used by all of the processes to store session information. Because the memory space of each process is mapped to the shared file, each process is able to access and manipulate all of the sessions in the system. Thus, sessions are no longer maintained on a process-specific basis. Rather, they are maintained on a centralized, shared basis. As a result, different requests pertaining to the same session may be serviced by different server processes without any adverse effects. Each process will be able to access and manipulate all of the state information pertaining to that session. By enabling session information to be shared, this mechanism eliminates the session management errors experienced by the prior art.

Abstract: A mechanism for enabling customized session managers to interact with a network server is disclosed. A programming interface enables customized session managers to “plug in” to and to interact with the server, making it possible to change session management functionality without having to make any changes to the core server. It also makes it possible to incorporate multiple session managers into the server. These aspects of the programming interface significantly increase the flexibility and scalability of the web server. The mechanism further includes a service engine for coordinating the interaction with the session managers. For each client request, the service engine determines which application needs to be invoked. Then, based upon that application, the service engine determines which, if any, associated session manager needs to be invoked to manage session (i.e. state) information for that application. The service engine invokes the session manager via the programming interface.

Abstract: A mechanism for enabling session information to be shared across multiple processes in a multi-process environment is disclosed. There is provided a shared persistent memory-mapped file in a file system, which is mapped to the memory space of each of the processes. This file is used by all of the processes to store session information. Because the memory space of each process is mapped to the shared file, each process is able to access and manipulate all of the sessions in the system. Thus, sessions are no longer maintained on a process-specific basis. Rather, they are maintained on a centralized, shared basis. As a result, different requests pertaining to the same session may be serviced by different server processes without any adverse effects. Each process will be able to access and manipulate all of the state information pertaining to that session. By enabling session information to be shared, this mechanism eliminates the session management errors experienced by the prior art.

Abstract: A mechanism is provided for enabling a request to be evaluated prior to the request being disposed. Particularly, an evaluation function is associated with a thread pool. Whenever a thread is to be assigned from that thread pool, the evaluation function may be invoked. The evaluation function may be invoked in response to one or more conditions being satisfied, or it may be invoked each time a thread is needed from that thread pool. When invoked, the evaluation function performs an evaluation on the request. Based upon the evaluation, the evaluation function may take one or more actions. For example, if the evaluation function determines that the request is a high priority request, then it may ensure that the request will be processed regardless of system workload. The evaluation function is user specifiable; thus, it may be programmed to perform any desired operations, and to take any desired considerations and factors into account.

Abstract: A JAVA application is typically executed as follows. First, a thread from a thread pool is attached to the JAVA virtual machine (JVM). Then, that thread is used to execute the JAVA application. Once the execution of the JAVA application is completed, the thread is detached from the JVM and returned to the thread pool. This is repeated for every execution of a JAVA application. Because this constant attaching and detaching of threads imposes additional overhead on the system, this process is inefficient. To improve the efficiency of the execution process, a “sticky attach” mechanism is provided. With sticky attach, a thread is not attached and detached from the JVM each time a JAVA application is executed. Rather, a thread is attached to the JVM only once: the first time it is used to execute a JAVA application. When execution of the JAVA application is completed, the thread is returned to the thread pool without detaching from the JVM.

Abstract: A mechanism for enabling customized session managers to interact with a network server is disclosed. A programming interface enables customized session managers to “plug in” to and to interact with the server, making it possible to change session management functionality without having to make any changes to the core server. It also makes it possible to incorporate multiple session managers into the server. These aspects of the programming interface significantly increase the flexibility and scalability of the web server. The mechanism further includes a service engine for coordinating the interaction with the session managers. For each client request, the service engine determines which application needs to be invoked. Then, based upon that application, the service engine determines which, if any, associated session manager needs to be invoked to manage session (i.e. state) information for that application. The service engine invokes the session manager via the programming interface.

Abstract: A mechanism for enabling customized session managers to interact with a network server is disclosed. The mechanism includes a programming interface which enables customized session managers to “plug in” to and to interact with the server. This programming interface makes it possible to change session management functionality without having to make any changes to the core server. It also makes it possible to incorporate multiple session managers into the server. These aspects of the programming interface significantly increase the flexibility and scalability of the web server. In addition to the programming interface, the mechanism further includes a service engine for coordinating the interaction with the session managers. For each client request, the service engine determines which application needs to be invoked. Then, based upon that application, the service engine determines which, if any, associated session manager needs to be invoked to manager session (i.e.

Abstract: Executing a thread unaware or non-thread-safe application in a multi-threaded environment is potentially hazardous. If multiple instances of the thread unaware application are executed concurrently in the same process space, as may be the case in a multi-threaded environment, one instance may try to modify or overwrite the information used by the other instance, which can lead to serious errors. To enable a thread unaware application to be executed safely in a multi-threaded environment, multiple thread pools are implemented. That is, for each thread-unaware or non-thread-safe application, a separate thread pool is defined and associated with the application. Unlike other thread pools, though, this thread pool has its maximum number of threads parameter set to “1”. By limiting the number of threads in the pool to 1, it is guaranteed that there will be no more than one instance of the thread unaware application executing at any one time.

Abstract: A mechanism is disclosed for implementing multiple thread pools in a computer system to optimize system performance. In accordance with the invention, a plurality of thread pools is initially allocated within a process space, with each thread pool comprising one or more threads. Each thread pool has a set of characteristics associated therewith, and the characteristics of each thread pool are customized for one or more particular types of service. After the thread pools have been allocated, the system receives one or more requests. When a request is received, it is processed to determine with which thread pool the request is to be associated. This processing is carried out by determining the type of service being requested by the request, and then determining which thread pool is associated with that type of service. Alternatively, this processing is carried out by extracting a set of indication information (e.g.