Ada, Ada multitasking with X-windows

Ada multitasking with X-windows

Author	Message
John Goods #1 / 4	Ada multitasking with X-windows Quote: >Subject: How do you (or would you) implement fork() in Ada??? >Organization: Wright State University >Disclaimer: All views are my own, and do not reflect the views of SAIC. >>TASKS ARE NOT THE ONLY WAY OF ... CONCURRENT ADA PROGRAMS >Because our group is having a little X-Ada-Unix program in the making, >we have the need for another approach. So, I thought of asking help >from people who know alot about Ada. >Heres the problem: >A 'callback' is added to a button (X Window System). This callback >is an Ada procedure. It must do slow SQL things. We do not want the >GUI to wait for this to complete. Instead, we want (through some >mechanism in Ada) the procedure, task or ???? to do its thing, and >then send raise an event 'got_SQL_stuff_event' to the GUI. >In 'C' you could do a fork with the parent not waiting for the >child to finish. >Insights, thoughts, criticisms are welcomed, encouraged but will not >be paid for except by our undying gratitude! >Marci Khader >SAIC X/Ada developer BEWARE! The current release(s) of X are NOT re-entrant (R4 and R5). There is locking macros in the source, but they are incomplete and the chances are that you're implementation uses the default null macros anyways. Xt is even less re-entrant. In fact, Xt will never be re-entrant in it's current design. Motif is no more re-entrant (indirectly in part because Xt is not re-entrant). In other words, multi-threaded applications which have more than 1 thread accessing Xlib, Xt, or any other toolkit layered upon Xt are faulty programs. See numerous previous discussions on comp.lang.x and previous discussions here on comp.lang.ada... Not to fret, however: It IS possible to develop multi-threaded X/Xt/Motif applications, but you have to design for it from the start. Only 1 task gets to do GUI stuff at a time, but you provide the necessary serialization. There are a couple of published methods on how to do this. NOTE: This means more than building a non-blocking event dispatch loop! IMHO, it is really the task of bindings vendors to develop and maintain such tasking safe bindings. I talked to Scott Cleveland at SERC, and he says that SERC is working on a tasking safe bindings for the next release of SA-Motif. ATC owes me a call, but I haven't heard back. Anyone from ATC reading this ? What's the word ? John Goodsen -- X-miester SETT, Inc. (an affiliate of EVB Software Engineering)
Sat, 17 Sep 1994 09:38:20 GMT

Marci Tabacc #2 / 4	Ada multitasking with X-windows Quote: >\| Subject: How do you (or would you) implement fork() in Ada??? >\| Organization: Wright State University >\| Disclaimer: All views are my own, and do not reflect the views of SAIC. >\| >\| Because our group is having a little X-Ada-Unix program in the making, >\| we have the need for another approach. So, I thought of asking help >\| from people who know alot about Ada. >\| >\| Heres the problem: >\| >\| A 'callback' is added to a button (X Window System). This callback >\| is an Ada procedure. It must do slow SQL things. We do not want the >\| GUI to wait for this to complete. Instead, we want (through some >\| mechanism in Ada) the procedure, task or ???? to do its thing, and >\| then send raise an event 'got_SQL_stuff_event' to the GUI. >\| >\| In 'C' you could do a fork with the parent not waiting for the >\| child to finish. >\| >\| Insights, thoughts, criticisms are welcomed, encouraged but will not >\| be paid for except by our undying gratitude! >You would be well-served to put the SQL stuff in a separate Unix process, >i.e., a database request server. This server is an Ada back-end program >with no GUI, merely handling IPC requests for a query and sending back >IPC responses with the results. (It might use X merely for IPC, or you >might just use sockets.) Then your Ada GUI program only has to deal >with the GUI, and with fielding the IPC responses, which you can do >without trouble, in X. >Use Unix processes to deal with the concurrency. >\| >\| X/Ada developer BEWARE! >And goes on to warn about the dangers of X and Xt non-reentrancy. >He is right on. However, if you have only one task dealing with the >GUI and your other tasks are doing "back-end" things, you may be >able to successfully use the Ada tasking model to deal with your >concurrency. >-- >Tom Chatt \ Don't take offense, take action. >UUCP: ...!uunet!flood!tom / \ we oppress ourselves. Thanks for the suggestions and valuable insight. Appealing and elegent as it may be, using Unix processes to implement the concurrency is a no-no, in light of the portability aspects. In my note, I did not elaborate on additional details (like future necessary ports, and signal handling between parent and child, in the case of fork()). So, John's suggestion, and Tom's confirmation (along with many other respondants) is well taken. There are still some details concerning the 'serialization of tasks' performing X calls. Put all of the GUI type calls in one task you say? Or use semaphores on all X calls? What are your thoughts about this? marci
Tue, 20 Sep 1994 21:25:35 GMT

Alex Blakemo #3 / 4	Ada multitasking with X-windows Marci Khader asked for help designing an interactive Ada X windows SQL program Quote: > In 'C' you could do a fork with the parent not waiting for the > child to finish. Tomm Chatt suggested Quote: > Use Unix processes to deal with the concurrency. Then Marci Tabacchi replied Quote: > Thanks for the suggestions and valuable insight. Appealing and elegent > as it may be, using Unix processes to implement the concurrency is > a no-no, in light of the portability aspects. fork() is a Unix system call to create a Unix process. It is not part of the C language. There is no reason why Ada programs are not allowed to call Unix (or other OS) routines. If depending on Unix is not considered portablem, then C should be held to the same standard. -- Alex Blakemore NeXT mail accepted
Fri, 23 Sep 1994 11:11:31 GMT

vanaverm.. #4 / 4	Ada multitasking with X-windows with standard_disclaimer; use standard_disclaimer; I think a number of issues have been confused in the heated discussion that followed. The first issue was that X and Xt are not thread-safe - you have to make all calls from one task. The same is probably true for (the implementation of) SQL (but I do not think that any particular SQL implementation was ever mentioned). Another (potential) problem that was not mentioned is that it might be a bit difficult to reconcile XtMainLoop with Ada tasking - but I have no experience with this. An issue that WAS mentioned, is that the developer wanted the X application to continue to function while the SQL operation was in progress. The problem there would be, that when a software layer (e.g., an SQL implementation) blocks a task, it might block the whole process (it depends, I suppose, on that software layer, on your operating system, and on the implemntation of the Ada run-time system). Some people have suggested separating this into 2 processes - I would agree. The client would do the X stuff, and the server would do the SQL stuff. They could communicate through a pair of pipes (Unix) or a pair of mailboxes (VAX/VMS). You would have to prevent the client from blocking (the whole process) while performing operations on those pipes/mailboxes - but that should not be too difficult. This solution would not be identical for the different platforms (the author of the original note did not mention which platforms he had in mind), but it would be similar - and the differences could probably be confined to a couple of package bodies.
Sun, 09 Oct 1994 20:03:24 GMT

Page 1 of 1

[ 4 post ]