RE: SDL-News: On implementations


Subject: RE: SDL-News: On implementations
From: Flávio J. Moritz Jr. (flavio.moritz#digitro.com.br)
Date: Mon Aug 16 1999 - 12:29:47 GMT


The originator of this message is responsible for its content.
-----From "=?x-user-defined?Q?Fl=E1vio_J._Moritz_Jr.?=" <flavio.moritz#digitro.com.br> to sdlnews -----

> Hmmm, what about defining an SDL process which handles the
> interaction with
> the database, and runs in its own thread ? This process would
> receive an SDL
> signal from another SDL process, whenever the database needs
> to be queried.
> It would then make the call to the database API in an SDL task. Upon
> returning from the database API, it would send back an SDL
> signal with the
> data retrieved from the database (with OUTPUT TO Sender).

That would be my dream comming true, but I'm not sure if SDT can generate
code in order to get SDL processes implemented as threads.
Vibhor Agarwal said Object Geode can and has a POSIX run time library suited
for that. Wonderful, isn't it?
I know SDT can generate code in a way that a SDL process gets implemented as
a separate O.S. process.
The said part of it is that I still would have to write down an environment,
with interprocess communication code, in order to get this SDL process, now
a OS process, to talk to another SDL process. That would be the same as
writing an interface middleware from scratch.

> Are you saying that this SDL process won't be able to send
> SDL signals to
> other SDL processes in different threads via SDL_Output in a
> thread-safe
> manner ?

Well, I assumed that from the following email I got from Telelogic's
personnel:

-------------------------------------------------------------------------beg
in quote---
Dear Flavio,
Regarding the question (below) concerning; thready safety.
I have received this answer from one of our experts.
No, it is not possible to use xGetSignal and SDL_Output in the way that
you want to. However, there is another way to do this.
The solution is to implement a message sending/receiving protocol
between your database thread and the SDLthread. The protocol should use
XInEnv and XOutEnv to send/receive signals to the SDL system.
This is the general way to deal with database queries from SDL.
Cheers
Tommy Bergstrom
Telelogic Support

> From: Flávio J. Moritz Jr.[SMTP:flavio.moritz#digitro.com.br]
> Sent: den 10 augusti 1999 15:46
> Subject: thread safety (ID:10266)
>
> Hi,
> I was wondering, how thread-safe is the generated C-code by SDT ?
> We're currently using TAU3.4, if that matters.
> Why am I asking this ?
> Because I want to start a thread to do some tasks and upon completion,
> use xGetSignal and SDL_Output to send a signal to some SDL process.
> Why would I want to do that ?
> In order to make a (SQL) database query from a TAU generated
> application without blocking this application in a database function call.
> How about it ?
> Is it possible ?
> How does everybody else deals with database queries from SDL ?
>
> []'s Flávio
-------------------------------------------------------------------------end
quote---

[]'s Flavio

> -----Original Message-----
> From: Yoni Rabinovich [mailto:YRABINOV#teledata.co.il]
> Sent: Sunday, August 15, 1999 3:33 AM
> To: 'Fl?vio J. Moritz Jr.'; sdlnews#sdl-forum.org
> Subject: RE: SDL-news: On implementations
>
>
> Hmmm, what about defining an SDL process which handles the
> interaction with
> the database, and runs in its own thread ? This process would
> receive an SDL
> signal from another SDL process, whenever the database needs
> to be queried.
> It would then make the call to the database API in an SDL task. Upon
> returning from the database API, it would send back an SDL
> signal with the
> data retrieved from the database (with OUTPUT TO Sender).
>
> Are you saying that this SDL process won't be able to send
> SDL signals to
> other SDL processes in different threads via SDL_Output in a
> thread-safe
> manner ?
>
> One other point: note that you can use the ##EXTSIG macro to
> optimize outputs
> to the environment (enabling you to simply make a direct
> function call to
> your "environment" function, rather than calling SDL_Output
> to send a signal
> to the environment pseudo-process). You'll need to tweak the
> code a little
> if you want EXTSIG outputs to be traced, though (but this is
> easy to do).
>
> > -----Original Message-----
> > From: flavio.moritz#digitro.com.br
> [SMTP:flavio.moritz#digitro.com.br]
> > Sent: 13 August 1999 14:46
> > To: sdlnews#sdl-forum.org
> > Subject: RE: SDL-news: On implementations
> >
> > The originator of this message is responsible for its content.
> > -----From "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > <flavio.moritz#digitro.com.br> to sdlnews -----
> >
> > Sure, Yoni.
> > We do exactly the same thing here.
> > But, lets get back to the database access problem.
> > Let's say the SDL application wants to make a query on a
> table stored in a
> > MySQL, PostgreSQL or even Oracle database server.
> > I can't see how I can use the environment functions to make
> this query
> > without blocking the whole SDL system.
> > Because this query will actually be a function call. The
> application will
> > return from this function call only after completion of the query.
> > So, things would work this way:
> > - The SDL process wants to make a query on a DB server,
> thus sending a
> > signal to the environment;
> > - xOutEnv is called by the SDT main loop to handle this signal;
> > - In xOutEnv, a function from the database client API is
> called to handle
> > the query;
> > - Query takes a lot of time, meanwhile the SDL system is
> freezed on a DB
> > client API function call.
> > So I was wondering if I could put this DB function call on
> a separate
> > thread
> > and use SDL_Output to send a signal from this thread to the original
> > thread
> > informing query completion.
> > But people at Telelogic told me that SDL_Output is not
> thread-safe. They
> > said:
> > -- quote ---
> > "The solution is to implement a message sending/receiving
> protocol between
> > your database thread and the SDLthread. The protocol should
> use XInEnv and
> > XOutEnv to send/receive signals to the SDL system."
> > -- end quote ---
> > Well, that's exactly how we do it now and I tell you, it's
> really boring
> > to
> > write this "middleware".
> > Unfortunately, I see no exit signal here. Thats the way it
> has to be done.
> > Oh, it just occured to me that a thread for you could be
> different from a
> > thread for me.
> > I'm talking about POSIX threads on UNIX OS processes.
> > A child thread shares most of the data from its parent
> thread, while a
> > child
> > process doesn't.
> >
> > Well, anyway, it's wonderful to see that I finally found a place to
> > discuss
> > this kind of things.
> > Thanks.
> >
> > []'s Flavio
> >
> > > -----Original Message-----
> > > From: owner-sdlnews#sdl-forum.org
> > > [mailto:owner-sdlnews#sdl-forum.org]On
> > > Behalf Of Yoni Rabinovich
> > > Sent: Friday, August 13, 1999 5:49 AM
> > > To: 'Fl?vio J. Moritz Jr.'; sdlnews#sdl-forum.org
> > > Subject: RE: SDL-news: On implementations
> > >
> > >
> > > The originator of this message is responsible for its content.
> > > -----From Yoni Rabinovich <YRABINOV#teledata.co.il> to
> sdlnews -----
> > >
> > > Hi Flavio,
> > >
> > > I developed a fairly large telecom application a few
> years ago with
> > > Telelogic's SDT (the SDL core of TAU).
> > > The way we handled issues like those you raise were by using the
> > > "environment" functions (xInEnv, xOutEnv etc.)
> > >
> > > The xInEnv function is called as part of the main loop
> of the SDT
> > > scheduler. Our SDT application ran on top of the pSOS Real
> > > Time OS, as a
> > > pSOS task (thread). External applications generated pSOS
> > > events when they
> > > wanted to pass data to the SDL system. The SDT main loop
> > > would check for
> > > such events in xInEnv, and translate them into SDL signals
> > > sent into the
> > > system. We designed it such that the SDL system would not
> > > block waiting for
> > > inputs from the external applications, so as not to block the
> > > SDL system
> > > itself. On the other hand, the SDT task would "go to sleep"
> > > if there was
> > > nothing for it to do (i.e. no internal SDL signals or timers
> > > or external
> > > events pending).
> > >
> > > Regards,
> > >
> > > Yoni Rabinovitch
> > > R&D Team Leader
> > > ADC Teledata Communications
> > > 7 Ha'sadnaot St, Hertzlia, 46120, Israel
> > > email: yrabinov#teledata.co.il
> > > Phone: +972-9-9591741
> > > Fax : +972-9-9591444
> > >
> > > > -----Original Message-----
> > > > From: flavio.moritz#digitro.com.br
> > > [SMTP:flavio.moritz#digitro.com.br]
> > > > Sent: 12 August 1999 22:14
> > > > To: sdlnews#sdl-forum.org
> > > > Subject: SDL-news: On implementations
> > > >
> > > > The originator of this message is responsible for its content.
> > > > -----From "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > > >
> > > > Hi,
> > > >
> > > > I've been lurking on this list for a while now and
> haven't seen any
> > > > discussion on SDL tools.
> > > > Well, I not actually interested in talking about the tool
> > > itself, but
> > > > rather
> > > > how people use these tools.
> > > > Let me give you an example.
> > > > I use Telelogic's tools (TAU) to design telecom applications.
> > > > It's (Telelogic's) C code generator implements the application.
> > > > Those applications are compiled and run on UNIX boxes.
> > > > Whenever I need to access a database server, I use interprocess
> > > > communications protocols to send messages to another UNIX
> > > process which in
> > > > turn uses the database API.
> > > > Just because I don't want my "SDL" app to block on a
> > > function call while
> > > > waiting for the database server.
> > > > So, I was wondering. How does anybody else do the same thing ?
> > > > How about shrinking this "middleware" into a thread ?
> > > > Wouldn't it be better ?
> > > > Can you see the kind of conversations I would like to have ?
> > > > Is this an appropriate forum for this ?
> > > > Can I start this kind of discussions here?
> > > > Does anybody knows a better forum for this?
> > > > Any mailing lists or newsgroups ?
> > > >
> > > > Please, don't take me wrong. I find people here very
> > > helpful. I just don't
> > > > want to bother you with things that aren't of your interest.
> > > >
> > > > []'s Fl?vio Moritz
> > > >
> > > > "The chase is better than the catch."
> > > >
> > > >
> > > > -----End text from "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > > > Join http://www.sdl-forum.org/Society/members.htm for extra
> > > SDL Forum
> > > > Society benefits
> > > > For help, email "majordomo#sdl-forum.org" with the body of
> > > your email as:
> > > > help
> > > > or (iff this does not answer your question) email:
> > > > owner-sdlnews#sdl-forum.org
> > >
> > > -----End text from Yoni Rabinovich <YRABINOV#teledata.co.il>
> > > to sdlnews -----
> > > Join http://www.sdl-forum.org/Society/members.htm for extra
> > > SDL Forum Society benefits
> > > For help, email "majordomo#sdl-forum.org" with the body of
> > > your email as:
> > > help
> > > or (iff this does not answer your question) email:
> > > owner-sdlnews#sdl-forum.org
> > >
> >
> >
> > -----End text from "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > <flavio.moritz#digitro.com.br> to sdlnews -----
> > Join http://www.sdl-forum.org/Society/members.htm for extra
> SDL Forum
> > Society benefits
> > For help, email "majordomo#sdl-forum.org" with the body of
> your email as:
> > help
> > or (iff this does not answer your question) email:
> > owner-sdlnews#sdl-forum.org
>

-----End text from "=?x-user-defined?Q?Fl=E1vio_J._Moritz_Jr.?=" <flavio.moritz#digitro.com.br> to sdlnews -----
Join http://www.sdl-forum.org/Society/members.htm for extra SDL Forum Society benefits
For help, email "majordomo#sdl-forum.org" with the body of your email as:
    help
or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:41 GMT