[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] writing concurrent code : possible with gnucobol?

From: Michael
Subject: Re: [open-cobol-list] writing concurrent code : possible with gnucobol?
Date: Sun, 1 Nov 2015 13:57:51 -0600
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Threads are actually allot of fun. A few years ago I was looking to
write a cobol app that could read and write to multiple non-blocking i/o
channels at the same time. So I once played around with GnuCobol and
threads, made some calls to pthread_create and such. Having multiple
threads running at the same time within a single cobol process was
pretty cool, but problematic to say the least.

Using only DISPLAY, it worked fine, each thread was successfully writing
to stdout simultaneously, the output was non-sense until I added some
"sleep" calls because each thread was writing over the other, but still
a success using multiple threads in cobol.

When I tried some math verbs like ADD,SUBTRACT, COMPUTE, DIVIDE and so
on, everything went south, erroneous results, and SEGV's. Even after
adding mutex locks and separate storage areas, still all math functions
failed. I didn't debug it any further, I just assumed that 'libcob' is
not thread safe, and stopped playing around with it.

Later made use of libev calls from cobol, which is an event library, and
I was able to read with timeouts and write to multiple non-blocking i/o
channels, even web-sockets using GnuCobol.

But in the end I decided to write an ANSI C library to manage such
things, and then link that to my cobol app. It goes to the philosophy of
using the right tool for the right job, where cobol is a application
development tool, and C is the tool for all the under-the-hood
complexities. To say it another way; You really don't want all that
complexity in your application code, it should be localized into library
function calls, making your application code much cleaner and easier to
debug, speaking for myself anyway.

Using an event loop is a cleaner way to write software that seems to be
doing several things at the same time, asynchronously. In reality, only
one event is being processed at a time using the event loop. In your
computer science class you may see terms like concurrent and parallel
processing, where concurrency speaks to having multiple threads running
in a single process, and parallel processing looks more like multiple
processes working on a common goal, at least that’s my take on it. Using
an event loop is clearner, and simpler. You can write a single-threaded
process that can seem to read and write to multiple files/sockets at the
same time in a single thread, and also handle other events and signals
simultaneously, timeouts, and so on. This is how all modern browsers
mange events, they may be multi-threaded, but only one thread is running
the event loop. You should note that running multiple event loops will
really make things difficult, don't do that!

Getting into concurrent and parallel event driven processing is hard,
and requires lots of planning and forethought. Using a single event loop
is much simpler because only one line of code is executing at any given

I am in the process of switching to libuv, a newer and better event
library, the same event lib used by node.js, Libuv works on Windows,
where Libev does not, but both can be called directly from GnuCobol,
however I prefer using a C wrapper.

Michael Anderson.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]