Mayuresh Kathe wrote: > hi, > > do cobol in general and gnucobol specifically possess any capabilities > that can facilitate writing programs which can take advantage of > today's multi-core hardware systems? > > suppose i wish to write a financial accounting system running atop a > gnu/linux based distribution like say ubuntu, would gnucobol run as a > single threaded process? or can i introduce concurrency? and is it easy > to achieve? > > if yes, any pointers for reading material would be nice to have. :) > > thanks, > > ~mayuresh Possible, but with care. The more critical the application, the more care that needs to be shown. When I coded up the libmicrohttpd example, I first just had it display some simple HTML, it worked, and I thought I was finished. Upon revisiting, some year and a half later, to make the sample look a little nicer, I added a CSS link inside the HTML. libmicrohttpd exploded into chaos, it had spawned a thread internally to load the CSS while the HTML object was loading. That causes the working-storage section of the callback handler to be shared, and the chaos ensued. A quick fix was moving critical data to a local-storage section, so the pointers and buffers used end up per thread and not just per process. Mutex locks would also be required for any purposely shared data. So, yes it's possible to thread GnuCOBOL, but it does not come "for free", design issues must be approached with care, and control flow, controlled. Bing google for "gnucobol libmicrohttpd" to find the thread. That discussion thread does not explicitly use threads, libmicrohttpd did that in the background, but it should not take much to create a test head using pthread_create and setting the start_routine as a PROGRAM-POINTER loaded with SET pp TO ENTRY "subprogram". During a CALL to phread_create the pp would then be passed BY VALUE, not by reference, as C will want the actual address, not the address of the COBOL pointer. Some, (most?, all?) the data inside the subprogram would need to be in local-storage or explicitly accessed through mutex routines. Depending on the sharing, even the data in local-storage might need said lock steps. We can talk more Mayuresh, if you end up needing more help. It might give me an excuse to write up another entry for the FAQ. And, although it doesn't really answer the question in any concrete way, Dr. Richard Hipp is not a fan of threads, and points to a UBerkeley article in the SQLite FAQ, Threads are Evil, Avoid them. http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf The fossil SCM is coded to work without threads, except in Windows where they could not get http servers to work without them. For mission critical applications, either great care must be shown, or alternative concurrency models should be sought. I'd be more than willing to help in that area, as GnuCOBOL deserves to be considered best of breed reliable if applied to concurrent financial scenarios. But, that is a heady area of computer science, a tad above my pay grade most days, but I'd be willing to help write tests for any models put in place. http://fossil-scm.org/xfer/doc/trunk/www/style.wiki https://www.sqlite.org/faq.html#q6 I'm a huge fan of Dr. Hipp, and I believe his views to be the correct views. Cheers, Brian ------------------------------------------------------------------------------ _______________________________________________ open-cobol-list mailing list open-cobol-list@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/open-cobol-list
